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I. IH TRO DOCTIOH 



A. BACKGBOOND 

In the early days of computing it vas simply man against the 
primitive operations of the computar. There was no need for 
any Command language because programming was done bit by bit 
without complex interfacing. Computer systems consisted of 
many tubes, a few cable connections, and possibly a periph- 
eral device to display the results (output). The programmers 
of the early days were considered jack of all trades. They 
designed the rudimentary programs, entered them bit by bit 
by re-arranging the cable configurations and should problems 
arise they were the only trained maintenance technicians. 
This idyllic situation did not persist for long. 

advances in computer technology especially in regards to 
resources available made it imperitive that the user be 
given some access mechanism to these resources. The first 
system to provide such a means was the IBM 360. The system 
required precise instructions to execute the system func- 
tions. Unfortunately, these instructions were not self 
generated like today's systems bur required external media 
intervention. This external media was in the form of punch 
cards each containing a precise coded instruction which was 
then feed into the system along with the program card deck. 
The system designers either misconceived the effect of these 
cards on programmers or miscalculated their abilities to 
achieve an automated system. The result was catastrophic. 
The first of the Command languages was a piece meal language 
conceived in part as an after thought to a poor system 
design. The IBM language called a JCL (Job Control Language) 
did just that, it controlled the program execution by the 
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insertion of instruction cards throughout the program 
manage the system’s resources. The language was ambiguous, 
rnconsistant , machine dependent and designed with little 
concern for the user. The impact of the IBM JCL language 
spawned numerous reserch efforts several of which are 
outlined. 

During the late 1960's and early 1970's several organi- 
zations established working groups to study the JCL and OSCL 
(Operaing System Control Language) interface problem. The 
first organization to study the problem was the American 
Standards Institute Committee on Programming Languges (ANSI) 
in June of 1967 [Ref. 1], They conducted extensive surveys 
of nine existing 0/S systems and their control languages. 
Their findings concluded with a list of five recommendations 



1. The need for a standard OSCL exists and its 
attainment is possible 

2. Several features now present in 0/S should 
not be included in the standard 

3. None of the existing OSCL’s surveyed are 
suitable as candidates fgr a standard language 

4. There should only be a single standard OSCL 

5. Piecemeal standardization should be avoided 
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Figure 1.1 ANSI OSCL Study Recommendations. 

for a design proposal, figure 1.1 

The Dutch established committees in September of 1971 
and conducted numerous meetings under the auspicies of the 
Netherlands Centre for Informatics. They focused on the 
basic functions of job control as related to data processing 
and job control inputs. The committee developed a list of 
basic job control functions. Figure 1.2, is a synopsis of 
their classification of related 0/S funcions. 
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1. Allocation (of resources) 

2. Conditional Selection (of part of a job) 

3. Execution (of a computer program) 

4. Declaration (of job attributes) 
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Figure 1.2 Dutch JCL Committee's Basic Job Functions. 

In late 1972 the CODASYL (Conference on Data System 
Languages) organization conducted follow on studies to the 
ANSI research. They determined that the ANSI committee had 
only addressed the feasability aspect of a standardized 
language and so set out to design a standard OSCL language. 
Three working goals were established to guide the research: 
investigate the functional requirements for communications 
between the user, the functional program and the hardware; 
determine the functions necessary to define a standard OSCL 
language and what problems such a language would have on an 
0/S; develop linguistic elements which posses rhese func- 
tions and define a m achine- independent OSCL. 

Since these early studies Other organizations i.e. US 
Federal Information Processing Standards (FIPS), IEEE, ACM, 
British Computer society, US Department of Defense (DOD) , 
etc. both government and privately sponsored have contrib- 
uted to the research and development of several prototype 
OSCL languages. 

The problem of standardizing Command Languages has 
perpetuated itself over the years. To date only a few 
languages (systems) merit any consideration as possible 
solut ions. 
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B. POfiPOSE 



The purpose of this project was ro design a system which 
will enable the user to easily define a screen oriented 
environment (shell) for interfacing to microprocessor based 
computer systems. 

The shell provides an abstract view of the computer 
system to the user. Through it command access can be 
controlled and a standard JCL can be created which will 
operate on multiple computers and operating systems. In 
this way, any computer system can be tailored to perform 
exactly as desired for each command. In addition, the same 
commands can be made to execute in exactly the same manner 
regardless of the resident operating system. This can have 
substantial cost saving effects in locations where multiple 
computers are used. Personnel will not have to be trained 
for each system since all systems will operate with the same 
JCL. 

C. SCOPE 

Chapter two discusses the issues involved in the design of a 
command language. Guidelines for the design are also 
presented. The features of the command language are 
described in Chapter three. Chapter four discusses the 

factors which were involved in the design. The assumptions 
made, the criteria established and the decisions based on 
them are listed. A prototype implementation is described in 
Chapter five. The operation of the system from the point of 
view of a user creating a shell environment with the command 
language is discussed in Chapter six. Our conclusions and 
recommendations including the results of the prototype 
implementation are presented in Chapter seven. Appendices 
A, B and C include the RSCL grammar, a User's Manual for the 
RSCL and a CLI program source code listing of the prototype 
implementation, respectively. 
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II. COMM AND LA NGD AGB ISSUES 



A. DESIGN ISSUES 

Four design issues confront the designers of any interactive 
Command language [Bef. 2]. First, how many modes of opera- 
tion should the user be forced to learn. Second, the selec- 
tion sequence of ccmmands should be consistent and not 
change with varying machine implementation schemes. Third, 
an abort mechanism must be provided to the user to terminate 
a command sequence without losing the current scope or envi- 
ronment. Finally, a clear and concise error message system 
must be provided to quickly resolve syntactic and semantic 
problems. These design issues are not all inclusive and 
further issues will be brought forward as the need arises, 

1. CCM^ICMION STYLES 

Many CL (command language) communication styles are avail- 
able today. Direct keyboard entry, using pre-defined 
commands, allows the user to directly control the machine 
operations, but requires the user to learn a new, possibly 
criptic, language for each OS/machine used. Another method 
uses keyboard response dialogue to screen prompts. This 
method is easier to use, but requires modification of the 
prompts whenever a change in functions is made. Function 
keys are a third method for users to communicate with the 
system. They are very fast and simple to use. The drawback 
with this method is some machines do not provide a function 
key option or an easy means to redefine the existing key 
functions. The last communication style to be mentioned is 
the screen menu format. This style is seen as the way of 
the future. Commands and data are displayed on the screen 
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in menu form. The user references the command/data bv posi- 
tioning the cursor at the desired field or by marking the 
position with a light pen. Data changed on the screen are 
correspondingly changed in the data base. Criptic one-line 
commands to the O.S. are no longer required. 

Some systems (Xerox Smalltalk) provide a controlled 
pointer (mouse) to indicate which function is to be invoked. 
The Apple Lisa system uses the position of the cursor to 
highlight a chosen function. In either case the system is 
screen oriented providing the user with a simple control 
mechanism without the need to learn another language. 

2 • desi^ guidelines 

Several scholars have suggested guidelines for developing 
command languages. Rather then repeat their offerings we 
have consolidated our perceptions of the primary guidelines. 

. The system must -be consistent. It must present 
the same environment to the user regardless of 
the basic system it is operating on. 

. The system must provide the user with a command 
sequence which is easy to use and learn, especially 
the most frequently used commands. 

. The system must be portable. Dther machines must 
be able to adapt to it with minimal modification. 

. The system must provide a suitable error handling 
process, both in presenting error messages and in 
saving environments. 

. The system should be user interactive and provide 
the user with the option of selecting the level of 
prompt help he desires. Screen oriented displays 
are very helpful in selecting operations, but 
require complex interface buffering. 
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, Control structures should be affluent enough to 
allow the user total control of the programming 
envircnment. 

3, USER PR OGR A tiaiNG LE VEL S 

Different levels of user motivation and programming experi- 
ence must be considered when designing a multi-purpose 
Command Language system. Figure 2.1 shows a rough categor- 
ization cf potential users into four general programming 
levels. 



1. The Toy Store Programmer 

2. The Novice Programmer 

3. The Computer Club Programmer 

4. The Paid Programmer 



Figure 2. 1 Four User Programaing Levels. 



The first level is the “toy store” programmer. He does not 
really want to write an application program, but just wants 
to know enough language tools to run a simple game program. 
In general, he is in total awe of computers and makes 
minimal use of their actual processing capabilites. 

Progressing to the second level, the first addres- 
sable command language level, we have the user who may have 
attended a programming course and who is now challenged to 
write a few simple application programs. The user at this 
level is enthusiastic and eager to try out his new skills. 
A friendly command language will motivate him to the next 
level. A poorly designed command language will be frus- 
trating and quite possibly curtail future computer queries. 

The third level is characterized by a quantum jump 
in user motivation. and usually programming skills. These 
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users really want to know how the internal system works and 
are willing to expend energy and their own time no learn 

system hardware and software configurations. 

The final level is a grouping of two user factions 
into one entity. They are colloguially termed the learned 
computer scholars and the commercial programmers. They may 
perceive issues from different perspectives, yet their 
motives and knowledge of computer linguistics are compat- 
ible. Beth require the full system resource capabilities at 
their immediate disposal in order no perform to their full 
potential. 

Realistically, the majority of today's users and 
those who are of ccncern to a command language designer, 
fall within the final two catagories. However, care should 
be taken so as not to preclude use by someone at the second 
level . 

It is easily understood why Command Languages are so 
universally divergent. Designing a command language to 
satisfy the dynamic needs of the fourth level users while 
still maintaining the simplicity for the novice users is not 
a trivial task. 

4. D ISPLA Y FORH ATS 

Another issue which is receiving a great deal of attention 
as the state-of-the-art is the display format. Whether to 
display data as individual line oriented character strings 
or as a menu driven system. The traditional theme, driven 
by the hardware limitations of the past, is TTY (teletyp- 
writter) format. i.e. Presenting a line at a time. The 
user responds in a similiar manner by entering data in line 
oriented fashion. Innovations in hardware have enabled 
designers to break from tradition and display whole screen 
prompts instantaneously. 
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The impact of these innovations has been seer, is 
such systems as the Xerox Smalltalk and the Apple Lisa, i. 
s. Incorporating the traditional command language line 
sditing commands into onscreen menu controls. The respose 
from critics to these nont raditonal systems has been over- 
whelmingly positive. 

The real significance of these systems is their 
prime objective. They strive to provide the user with a 

friendly interface devoid of complex, ambiguous and incon- 
sistant command language structures. To the "real” program- 
mers these systems appear as a threat to their mythical man 
over machine syndrome. Many feel that programming is an art 
and a science and that these systems take away their 
creativity by restricting how they can address the computer. 
They prefer to deal direct rather than through the 

middleman. In reality, a friendlier interface places no 
such restrictions. It simply makes it mors understandable 
so that more users can address the computer direcly. On til 
we overcome the system friendliness problem only those in 
the "real" programmers category will be willing and able to 
fully utilize the computer. 

These systems still have some drawbacks such as 
overall cost and high memory requirements. Yet, given the 
history of the microprocessor, hardware designers will over- 
come the obstacles and make these features available to the 
average user. 

The command languages of tomorrow will employ the 
ease of onscreen ccntrol with the user friendliness of 
multi-screen display. 
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III. HSS CO^AND LAS GOAGB FEATOHES 



A. BSCL COMMANDS 

The RSCL commands were c 
outlined in chapter two. 
conciseness in definition 
choosing the RSCL commands. 
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all possible programming 
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Exception processing and t 
nor is it implied in any 
does not know what you inte 
message. If data types d 
operation, the assignment i 

1 . BOILT IN FEATURES 

Several features have be 
simplify both the language 
in the language. 

. Dynamic data typing (of 

. Both interactive and fi 



Automatic file opening 



hosen based on the guidelines 
Simplicity of use, coupled with 
and execution were oaramount in 



experien 
er to ba 
hile the 
language 
rements o 
ser frian 



ce indicates 
rogue or to 
RSCL does not 
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f a complete 
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that many 
simple for 
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it does 
langua ge. 
a design 



conventions i.e. if-t hen-else, 

d whenever possible. The syntax 
from established norms, while the 
d language avoids ambiguity, 
ype conversion is not performed 
of the commands. If the system 
nded, it tells you via an error 
o not match across an assignment 
s not permitted. 

en built into the RSCL which 
itself and the programs written 



fsets declaration reguirements) . 
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and closing operations performed 
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on both the POr and the GET commands. 

. Fermat free statement entry. 

. Statements may be entered in either upper or lower case. 
2 . L ANGGR GE LI MITAT IONS 

The language, as designed, has the following limitations: 

. Arrays and data structures are not defined. 

. Only decimal integers may be represented. 

. Floating point arithmetic is not supported. 

. Unary operators are not supported. 

. Exponentiation is not supported. 

In the prototype implementation the following addi- 
tional contraints were placed on the system: 

. Loop statements may not be nested. 

. Only one string variable may exist at any time. 

3 . L MSMi E COMMANDS 

The ten RSCL commands were chosen as the minimum number 
required to facilitate the requirements of a screen oriented 
command language. 

The following is a brief description of each 
command. For a detailed description see the R&s Command 
Language User’s Manual, Appendix B. 

a. LET command 

The LET command serves as the assignment statement. The 
variable on the left hand side (LHS) of the '•='*, receives a 
value from the right hand side (RHS) . The RHS can be either 
an expression, an integer, a string, or another variable 
(containing a value of the same data type) . If the RHS is a 
legal arithemetic expression, its value is computed and the 



20 



result is assigned to the variable on the LHS. Otherwise, 
the value of the RHS is directly assigned to the variable on 
the LHS, 

b. The PUT command 

The PUT command consists of three parts; the device, an 
optional line skip parameter and the data list. It outputs 
newlines and the items specified in the data list to the 
named device. 

Valid devices are: "LST", the system line 

printer; ''CRT'', the user’s console screen and <FN> the name 
of a disk file. The device name may be followed by the word 
'•skip" (performed only once per*command) . Bach occurrance 

causes a newline character to be output. The data list 

contains any combination of variables and strings (a string 
consists of any characters contained within double quote 
symbols ” •') . The value of the variable and the actual 

character string, minus the quote marks, will be output. 

c. The GET Command 

The GET command reads data from either the user's console or 
from files stored on the user's disk. The device name 
("CRT”, <FN>) preceeds the receiving variables and indicates 
which medium the user wishes to access for his data. 

d. IF command 

The IF command is used to logically select whether or not to 
execute a particular set of statements. It has three compo- 
nents; a logical expression, a THEN set of statements and an 
optional ELSE set of statements. The value of the logical 
expression is computed. If the expression result is true, 
(value not equal 0), the THEN group of statements is 

executed. Otherwise, the ELSE group of statements is 

executed. If no ELSE group is included execution continues 
after the end of the IF statement. 
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e. The CASE Command 

The CASE command provides for the execution of one or more 
statements contained within at leasr one sub_case. The 
sublease is entered if it.'s corresponding case label matches 
the value of the CASE statement parameter (variable or 
integer) . If no sub_case label matches the label of the 
case value, the OTHERWISE set of statements is executed. 

f. The LOOP command 

The LOOP command consists of two parts; the loop iteration 
parameter and the body of statements. All of the statements 
included within the body of the loop are repeated a number 
of times equal to the value of the loop iteration parameter. 
If this value is less then or equal to 0, no statements are 
executed. 

g. The COMMENT Command 

The COMMENT command performs no actual processing. Its 
purpose is to allow the user to document his program and to 
structure it in a logically understandable form. A comment 
begins with a and, as all other RSCL statements, it 

terminates with a Everything contained within these 

two semicolons is ignored. 

h. The LOCATE Command 

The LOCATE Command is used to determine the current location 
of the cursor. It returns the row and column number. 

i. The POSITION Command 

The POSITION Command is used to place the cursor at a 
particular point (row and column position) on the screen. 
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j. The CREATE Command 

Tha CREATE Commatnd is used to generate a screen template. 
It consists of two parts; the template identifier and from 1 
to 24 line definitions. 

The template identifier is a Vcuriable name used 
to differentiate one template from another. The line defi- 
nitions specify up to 80 fields per line and their associ- 
ated attributes. 

k. The DISPLAY Command 

The DISPLAY Command causes a screen templare and its associ- 
ated data to be output to tha user’s console screen. It 
consists of two parts; the template identifier and an 

optional set of parameters. 

The template identifier is a variable name 
supplied by the CREATE command when it generated the temp- 
late. The parameters include a line number, a field number 
and text. The line and field numbers specify exactly where 
on the template the* text has changed. These parameters are 
returned by the display manager whenever the data in a 
particular field has changed. 
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17. SISTEH DKIGH 



1. DESIGN ASSONPTIONS 

Eour major design assumptions were made early in the design 
phase. First, the integrated sysram is intended to operate 
on either 8 or 1 6 bit microcomputers. 

Second, the interfaces between the host operating 
system, the command language and the Display Manager are all 
transparent to the user. The use of abstract interfaces 
between these three modules enables the system to be readily 
transportable to various microcomputers and operating 
systems. 

Third, memory utilization was not considered a prime 
concern. The current trends in the state of the art rewards 
larger, cheaper memories lead us to believe that the differ- 
ence of one or two thousand bytes out of possibly one mega- 
byte of storage is insignificant. 

Fourth, processing speed was considered important, 
although not paramount in the design. Since the system is 
to be in coatinuous operation serving as the interface 
between the user and the imbedded operating system, some 
overhead is acceptable in exchange for the added capabili- 
ties. This overhead should occur during the user's "think” 
time rather than during actual processing. 

B. DESIGN CRITERIA 

Several criteria were considered daring the design phase. 
Clarity, simplicity, portability, maintenance and upward 
compatibility were all key factors in designing the system. 
The ultimate goal was to design a system that incorporated 
the features outlined in Chapter two in a clear and concise 
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manner without overburdening the user. The limited number 
of language commands is a direct attempt to demonstrate that 
a command language can be simple and can function clearly 
without an excessive number of nebulous commands. The 
sample programs listed in the users manual demonstrate the 
clarity of command usage. 

The use of a high level system programming language, 
"C”, serves to grant the desired portability. "C compilers 
are available on many micro, mini and mainframe systems. 
Cross-compilers should be available for those systems which 
do not have a "C* compiler. 

The VAX computer was used for development of the proto- 
type system. Its processing capabilities and myriad of 
supporting functions along with its multiprogramming oper- 
ating system and the availablity of a competent support 
staff made it more suitable for development than a single 
user micro system. The use of any features unique to the 
VAX is purely accidental. To assure program portability, 
only standard "C” programming features were used. 
Extensions and system dependant features must be avoided in 
any implementation. 

Program maintenance is supported by the use of a higher 
order programming language, functional decompostion, 
abstract interfaces and structured programming techniques. 
The utility of these factors was directly observed during 
the debug and test phases of the prototype implementation. 

In addition, the use of a higher order language, the 
simplicity of the language design and the avoidance of 
nonstatndard features ensures soma degree of upward system 
compatibility. 
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C. DESIGH DECISIONS 

Three major design decisions were faced during the develop- 
ment of the command language. First, which language should 
be used to implement the system. Second, certain grammar, 
structure and i ip lamentation conventions had to be adopted 
in order to ensure system integrity. Third, the interfaces 
between the operating system, the Command Language module 
and the Display Manager module was uncertain. 

*'C” was chosen to implement the system because of its 
inherent system design features, it was originally designed 
as a system development tool. As such, it was felt to be 
the most suitable language for our purposes. 

In designing the RSCL grammar, standard conventions for 
representing the lexical ordering and syntax of the language 
were devised. These conventions were documented and are 
included with the grammar itself in Appendix A. The use of 
these standards was necessary in order to assure that we 
both interpreted the grammar in a like way and that separate 
modules, which were coded independently, would operate in a 
like manner. 

Prior to initiating the actual coding phase, several 
sessions were held to establish programming guidelines and 
intermodule interfaces. Global variables, data types, error 
handling, system diagnostic and integration standards were 
defined. Any changes or variations from these established 
guidelines were discussed and agreed upon before being 
incorporated into the respective functions. This practice 
proved to be invaluable daring the integration and test, of 
the prototype system. No significant interfacing problems 
were encountered. 

The last major design decision concerned interfacing the 
command language interpreter (CLI) wirh the resident oper- 
ating system and with the Display Manager program. Neither 
of these interfaces was built .into the current system. 
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Instead, abstract interfaces were planned for each of 
these. The operating system interface will be a function 
call with a character string parameter. For example, to 
change the name of a file, a rename function would exist. 
This function would require two parameters; the old file 
name and the new file name. The file names are expected to 
be complete. Information such as the disk drive designator 
should be included in the name whether or not the user 

enters it. The rename function would then cause the oper- 

ating system to change the name of the file in whatever ways 
it feels is optimal. It is rransparent and irrelevant to 

the (CLI) , whether a separate command to the operating 

system is generated or the data is sent to the BIOS or the 
disk file directory is changed. In this way, a change in 
the underlying operating system will require a change in 
only these interface functions. It makes no difference to 
the majority of the system whether a file name is changed by 
an "mv” command as in VAX UNIX, an "ren" command as in CP/M, 
an "r" command as in VMS, etc. The implementation of these 
functions is currently the topic of a separate thesis at the 
Naval Postgraguate School. 

The interface to the Display Manager module was not 
implemented because it was planned to use a pre-existing 
program. A commercial product, called "Display Manager" is 
available from Digital Research. This program does all that 
we needed in the RSCL system. It also is capable of inter- 
facing directly with a program written in the "C" language. 
Rather than devote time to development of a new program with 
similar capability, it was decided to purchase and use the 
Digital Research Display Manager. Our efforts were spent 
defining the display data which were of concern. This 
information is included in the language grammar within the 
"create" command. The actual commands telling the Display 
Manager what to display are included in the grammar within 
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the "display" command. Coding of these functions was post- 
poned until the program could be purchased. At that time 
the actual interfacing parameters reguired can be determined 
and the functions can be written. 
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A. DATA ORGANIZATION 

The language data organization is broken up into two parts, 
local and global variables. Local variables are used within 
each function to handle internal data transactions. Data 
shared between two functions is passed globally. The global 
variables are declared in a central file, "global, interp'*, 
to maintain tight control over their assignment and use. 
Using global variables to transfer external data decreased 
the system execution time, while making the functions 
cleaner and easier to integrate. The design specifications 
clearly define each global variable, its use and what func- 
tions utilize it's values. 

Comments are generously dispersed throughout each func- 
tion to aid the user in understanding its purpose. A header 
is appended to the beginning of each function, listing the 
other functions called and the global variables and 
constants used within the function. 

B. PROGBAH ORGANIZATION 

Functional decomposition was used extensively throughout the 
program. Three separate modules comprise the fully inte- 
grated system. The 0/S module is a set of functions which 
defines the interface to the host's operating system. These 
functions translate commands from the CLI to the native 
language of the 0/S. Those commands that are not native to 
the host will be software emulated, if possible. 

The language interpreter module has a dual function. It 
interfaces with both the 0/S and display modules. Programs 
generated either interactively or by batch mode are 
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processad through the language interpreter. Output from rhe 
interpreter is a series of instructions to one of the other 
two modules. 

The last link in the triad is the display module. Like 
the 0/S module, it receives its data from the interpreter 

through the interface commands. The display module takes 
data stored in a file and transposes it onto one of the 
formats generated by the create command. 

C. ROHTIME ERROR CBECKING 

A run time error handler is built into the system and is 
activated when an invalid command sequence is encountered by 
the interpreter. All error messages are contained in a 
single error function. When an error is detected the error 
handler is called and prints a diagnostic message and ampli- 
fying information. Depending on the severity of the error 
either the program is terminated or control is returned to 
the^ calling function. 
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VI. SYSTEM OPER&TION 



The RSCL is capable cf operating either in an interactive or 
a batch mode. For batch mode operation, programs can be 
written using any standard text editing program. The file 
containing the source code must be called "RSCL'*. 

At execution time, the CLI determines if a file exists 
with the name "RSCL", If one is found, it is assumed to 

contain the source statements. The CLI then executes in a 
batch mode taking its input from the source file. 
Otherwise, the CLI reads its insncuctions from the user's 
console. 

When operating in an interactive mode, the user must 
still follow the complete format of the language structure. 
That is, the program begins with the word "program", termi- 
nates with the word "end. " and each statement terminates 
with a 
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VII. CO NCLDSIO NS A MD HEC O HBEHDATION S 



The command language design and a prototype implementation, 
have been completed. This design is now reviewed to deter- 
mine which of our original goals have been met or can be met 
with further work and which, if any, were not found to be 
feasible. 

A. GOALS 

The goal of this work was to design a command language which 
runs on microprocessor based computer systems. The purpose 
of the language was to allow rapid definition of a screen 
oriented user interface. The language was to be simple, 
easy to use and readily understandable. Maintainability and 
portability across different machines and operating systems 
were prime concerns. Processing efficiency was considered, 
but only secondarily to the other factors. 

B. PBOBLEH AREAS 

The RSCL is complete and workable as designed. Known 
problem areas which are stated as constraints in the 
language are not inherent problems. They can be eliminated 
during future enhancements. The only area which we see as a 
potential problem to the system design is related to the 
Display Manager interface. The design in this area was 
purposefully made generic via the principles of abstract 
interfaces and irformation hiding. However, if the func- 

tions required by the CLI are not available, some redesign 
may be necessary. Because of our research in the area 
before creating the design, we do not feel this is a major 
concern. The CLI module should be easily interfaced -.o the 
other two major system modules when they become available. 
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C. FOTOBE WORK 



In order to create a complete and deliverable product 
further work is required in four areas; the operating sysrem 
interface routines must be completed, enhancements must be 
added to eliminate the constraints discussed in Chapter 
three, the three main system modules must be integrated, 
studies should be performed to determine user needs and 
reactions. 

The operating system interface routines are already 
being developed under a separate thesis effort at the Naval 
Postgraduate School. Assuming that a copy of the Display 
Manager Program is obtained from Digital Research and that a 
'•C compiler is available for the NPS microprocessor system, 
the system enhancements and module integration can be accom- 
plished under another thesis. Concurently with the system 
integration, research should be performed to determine 
sample presentation formats. They could then be created in 
the RSCL. 
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appendix a 

COMMAND LANGUAGE GBAHBAB 



The conventisa ased for describing the 
command language is described in table i. 



grammar 



of 



the 





TABLE I 

Grammar Convention 




SYMBOL 


MEANING 








< > 


Used as delimiters for metasymbols 
in the grammar. Anything contained 
within these brackets is defined 
later in the grammar. 




C ] 


Used as delimiters surrounding 
optional entries. 




1 f 


Used as delimiters surrounding 
literal expressions in the grammar. 
Anything within these symbols must 
appear exactly as shown. 




1 


Used as a logical OR. 




• • 


Interpreted as "Defined as". 




( ) 


Used to group expressions. 




♦ ♦N 


Used to designate a repetitive group. 
Where "N" is the number of repetitions. 


J 



Using this convention the Command Language Grammar is 
defined as follows; 

PROGRAM :;= 'PROGBAM* <IDENTIFIBR> <STATEMENTS> 'END.' 

STATEMENTS : := ( <LET STATEMENT> I <IF STATEMENT> 

<PUT~STATEMENT> | <GET STATEMENT> 

<LOOP STATEMENT> I <CAPE STATEMENT> 
<C0MITENT> i <DISPLAT> | ^CREATE> ) 

[ <STATEMENTS> ] 
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LET_STATEMENT 

IF_STATEMENT : 

PUT.STATEMENT 

PUT_DEVICE 

LIST 

GET_STATEMENT 

GET^DEVICE 

ID_LIST 

FNAME 

LOO?_STATEMENr 
CASS_STATEMENT 
CASE NUM ::= 



COMMENT 

IDENTIFIER 

SaB_ID 

EXPRESSION 

SUB_EXP 

TERM 

LOG_EXP 

SDB_LOG 

LOG_TERM 

SPACES 

NUMBER 

CHARACTER 



DIGIT ::= 'O' 



:= 'LET' <IDENTIFIER> •=' ( <EXPRESSION> 

J <IDENTIFIER> | <NUMBER> | <STRING> ) 

= 'IF' <L03 EXP> 'THEN' <STATEMENTS> 
['ELSE' <STATEMENTS> ] 'ENDIF' 

'POT' <POT_DEVICE> [ 'SKIP' ] <LIST> 

'CRT' I 'LST' I <FNAME> 

( <IDENTIFIER> | <STRING> ) [<LIST>] 

'GET' <GET_DEVICE> <ID_LIST> 

'CRT' I <FNAME> 

<IDENTIFIER> [ <ID LIST> ] 

f 



<CHARACTER> ':' ] <IDENTIFIER> 

'.' <IDENTIFIER> ] 



'LOOP' ( <IDENTIFIES> ( <NUMBER> ) 
<STATEMENTS> 'ENDLOOP' 

'CASE' <IDENTIFIER> ':' <CASE NUM> 
'OTHERWISE:' <STATEMENTS> 'ENDCASE' 



(<NOMBER> I <IDENTIFIER>) 
[ <CASE_NUH>] 



<ST ATEMENTS> 



>a • • • 



<ANTTHING> 

<CHARACTER> [<SUB_ID>] 

[ '_' ] (<CHARACTER> | <DIGIT>) [<SUB_ID>] 

' (' <TERM> [ <ARITH_OPR> <SUB_EXP> ] ')' 

<TERM> [ <ARITH_OPR> <SUB_EXP> ] 

<EXPRESSION> I <IDENTIFIER> | <NUMBER> 

' (' <LOG_TERM> [ <L03_0PR> <SUB_LOG> ] ’ 

<LOG TERM> [ <LOG OPR> ( <S 06 LOO 
\ <LDG_EXP> ) ] " 

<LOG_EXP> I <IDENTIFIER> | <NUMBER> 

' ' I ' ' <SPACES> 

<DIGIT> I <DIGIT> <NUMBER> 

' G' 

' N' 
'O' 

' b' 

' i' 

' P' 

' w' 



) 



= ' A' 


'B' 


' c 


' D' 


• E' 


'F' J 


' H* 




'j' 


'K ' 


'L' 


'M' 


' O' 


'P' 1 


•Q' 


'R' i 


'S' 


• J • 


' V 


'W' 


'X' 


' Y' 


' Z' 


•a' 


' c' 

* j' 


'd' 


'e' 


'f ' 


• g. 


'h' 


'k' 




' m' 


'n' 


'o' 


' g' 

' X' 


'r' 

•y 


's' 
' z ' 


»t' 


'u' 


'V' 



' 1 ' 
'3' 



' 2 ' 

'9' 



I '3' I 



I '6' I '7' 



ARITH_OPR :•:= ' + ' | 



I - 1 



I 



LOG_OPR ::= 'EQ' I 'LT' I 



• ♦* 

' GT' 



'/• 

•NE' 



I 'LE' I 'GE' 
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LOG_FDNC :: 
STRING :;= 
ANYTHING :: 

OTHERS :: 

DISPLAY ::= 
PARAMS :: 

LINE : : 

FIELD :: 
TEXT :: 

LOCATE :: 
POSITION 
ROW : : 

COL : : 

CREATE :: 
DEF_LINE :: 

DEF_FIELD : 
ATTRIBUTES 



LENGTH : 

VALUE : 

ACCESS : 

FOREGROUND 
BACKGROUND 
VIDEO : 

UNDERLINE 
INTENSITY 
TYPE : 



= 'AND* I ‘OR* 

' " <ANYTHING> • 



I 'NOT* I 'CON' 

I t 



= ( <DIGIT> j <CHARACTER> | <ARITH OPR> 
I <OTHERS> [ <ANYTHING'J ] 



- Ill 

• . I 

• i • 



• (• 

• I • 

• =• 

I I 
f 



•55 



• I • $• I • I • 

• I • II • I • • 



•a ' I • #• 
•<• I •>• 



•DISPLAY' <IDENTIFIER> [<PARAMS>] 
= ' (• [ <LINE> 



<TEXT> ] ' 



= NUMBER 
= NUMBER 
= ANYTHING 
= 'LOCATE' <ROW> 
= 'POSIT' <ROW> 

= NUMBER 
- NUMBER 

= 'CREATE' <IDEN 

= ' DEF LINE' <NU 
( <DEF_FIELD>* 

:= 'DEF_FIELD' < 

t= • (• r<LENGTH 
< ACC ESS 
<FOREGR 
<UNDERL 
<TYPE>] 



[<FIELD>] ',' 



<COL> 

<COL> 



TIFIER> <DEF_LINE>**2U 'END' 

MBER> r ' - • <NUMBER> 1 
♦80 I ^BLANK' ) 'ENDLINE 

IDENTIFIER> <ATTRIBUTES> ';• 



• • • 



>] ',' [<VALUE>] ',' 

>1 ',' [ <BACKGROUND>] ',' 
OUND> ] S • r <VIDE0>1 • , • 
INE>] ',' r<INTENSlfY> 1 ',' 

I j I •' 



= NUMBER 
= ANYTHING 
= 'R/0' I 'R/W' 

DIGIT 
:;= DIGIT 

= • NORMAL ' I 'INVERSE' 

:= 'ON' I 'OFF' 

:= 'BRIGHT' I 'DIM* 

= 'ALPHANUM* I 'NUMBER' | 'CHAR' | 'STRING' 
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APP^MX B 

S&S COMMAND LANGUAGE (JSEE*S MANUAL 

A. INTRODUCTION 

The RSS Ccmmand Language (RSCL) is designed to create micro- 
processor shell formats from within user designed software 
programs. Programs written in the language will interface 
with the display module to output data in the specified 
screen format. Menus are utilized to facilitate program 
entry and apprise users of available formatting options. The 
language uses an interpreter, written in "C, to execure the 
programs. 

B. LEXICAL CONVENTIONS 

There are seven types of tokens: identifiers, integers, 

strings, arithmetic operators, logical operators, logical 
functions and others. In general blanks, tabs, commenrs and 
newlines are ignored except as they serve to separate 
tokens. At least one of these characters is required to 
separate otherwise adjacent identifiers. The language does 
not incorporate any reserved words in the grammar. Each of 
the RSCL statements is considered a keyword when used at the 
beginning of a command sequence, however, since keywords are 
not treated as reserved words they are allowed to be 
assigned as identifiers latter in a command line. The semi- 
colon acts as a statement terminator. 

1 , TOK^N DESCRI PTIO NS 

Each word is scanned for inclusion in one of the seven iden- 
tified token types. The tokens are then processed one at a 
time through the CLI. The following subsections describe 
the token formats in detail. 
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a, IDENTIFIERS 



Identifiers may consist of alphanumeric characters and the 
underscore symbol. The first character must be alphabetic. 
It is optionally followed by characters, underscores or 
digits. Upper or lower case alphabetic characters are 
allowed tut are not distinguished. The standard convention 
of not allowing an identifier to terminate with an under- 
score applies. Identifiers have a maximum length of ten 
characters and their value can be one of three types: char- 

acter, string or integer. 

BHF format; 

IDENTIFIER ; ;= <CHSRACTER> <SUB^ID> 

SUB_ID ::= ( <CHARACTER> | <DIGIT> ) <SOB_ID> 

b. NUMBERS 

Numbers are formed by conca tinating one or more digits onto 
a digit. Only digits are used to form numbers. Numbers are 
not re-definable data types. 

BHF format; 

NUMBER ::= <DIGIT> | <DIGIT> <NUHBER> 

DIGIT ;:= *0 • I '2' r3* I '4' I' 5» I' 6' I ' 7* I '8' 1 ' 9’ 

C. STRINGS 

Strings are any ASCII print character (s) between double 
quotation marks (*' *') . The language reads "this is a 

string" as a single string. 

BHF format; 

STRING <ANYTHING>' "• 

ANYTHING ( <DI GIT> | <C HARACTER> | 

<ARITH 0PR>| <OTHERS> <ANYTHING> 
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d. ARITHMETIC OPERATORS 

Standard arithmetic operators i.e. " + ti*n^ n/n 

implemented within the language. Unary operations are nor 
currently supported by the language. 

BHF format; 

ARITH^OPR ::= | i -i | • *i 1 1 /« 

e. LOGICAL OPERATORS 

Alphabetic type characters i.e. ”EQ", ”LT", "GT", "NE”, 

"GE" , "LE” are used to perform logical operations. The 
first three equate to equals, less then, and greater then 
respectively. The last three equate to not equal, greater 
then or equal, and less then or equal. All expressions are 
required to be parenthesized i.e. (A GE B) or (4 LT 9). 

BMP format; 

LOG_OPR ;;= * EQ' | ' LT* | 'GT ' | ' NE ' | ' SB ' | ' LE » 

f. LOGICAL FUNCTIONS 

Logical functions also use alphabetic type characters i.e. 
'•AND", "OR", "NOT", "CON" to perform their functions. The 
"AND", function returns true if the two arguments bracketing 
the "AND" are both true. The "OR" function returns true if 
either of the bracketing arguments is true. The "NOT" func- 
tion logically complemnts its operand. The "CON" function 
concatenates a string onto another string. Like the logical 
operators, parentheses are required in logical expressions 
i.e. ( (Z GE D AND (M LT H)) where Z, T, H, and w are vari- 
ables or expressions which evaluate to comparible data 
types. 

BNF format; 

LOG FONC ; ;= 'AND* I 'OR'I ' NOT’I ’CON' 
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g. OIHERS 



The others token type is a collection of the remaining stan- 
dard ASCII print character types i. e. "("» ")"r 

etc* These characters represent their normal meaning 
except where their meaning is negated i.e. ’*gT'* replaces 
sign in the grammar convention. 

BHP format: 

OTHERS :;= ' ' ' I ' ( ' I ') ' I ' ! ' I ' : ' I ' ? ' I ' i ' I ' I ' I ' 3 ‘ I ' # * I ' S * | ' 

|i I nil 1 1 • I •<• I •> ' I ' I ' » • I ' ' 



C. DECLARATIONS 

The language does not provide for any variable pre- 
declaration. New variables on the LHS or RHS, if reading in 
data from the CRT (screen) or a file, will be assigned the 
same data type as the recieved data automatically. Type 
conversions are not performed in the language. 

D. SYNTAX 

The BNF (Backus Naur Form) syntax sx.ructure for the grammar 
is provided in Appendix A. 

E. PBOGRAH STBOCTORE 

All programs written in the RSCL are comprised of three 
parts; a header, statements to execute and a trailer. 
Figure B.1 shows the format of a simple program. 

This sample demonstrates the overall program structure. The 
first line, "program sample" is the program header. Note, 
that it does not include a semicolon. A semicolon is a 
statement terminator (a semicolon is required at the end of 
every statement) . The complete statement is "program test 
<executahle statements> end.;". 
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program sample 

put crt skip '’Enter a value for the loop count."; 
get crt a; 
loop a 

if ( a eg 2) 
then 

put crt "The value of a is " a; 

9lS6 

get testfile.dat b; 
put crt skip "When a = 2, b = ** b; 
enHif ; 
endloop ; 
en d. 



Figure B. 1 Sample Command Language Program. 

The second through twelfth lines ace the executable state- 
ments. They perform the actual processing. The trailer is 
"end. 

The indentation and structured appearance is optional. 
The CLI ignores blanks and carriage returns. Therefore, 
multiple statements can be placed on a single line and a 
single statement can be split over several lines. Figure 
B. 2 shows two legal ways to write rhe same statements. 



I 1 

Sa mple of combined lines . 
let a = (b>1) ; put crt a; 

Sample of li^ sp litt ing . 

let 
a= ( b 



; put crt 
a ; 




Figure B. 2 Example of Two Line Formatting Techniques. 
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while no one should write a program in the second 
format, if the code needs to be packed, any format is accep- 
table so long as variable names are not split between lines. 
In that case they will be treated as two separate variables. 

Now, knowing the general structure of an SSCL program, 
each of the ten individual statements are discussed in the 
following sections. Each statement's function and format, 
the constraints on its use and the error messages which can 
occur with their probable cause (s) are described. 

iSI Stat emen t 

The LET statement is used to perform arithmetic operations 
and to assign values to variables. When performing arith- 
metic, the expression on the RHS must be contained within 
parenthesis. The value of that expression will then be 
assigned to the variable on the LHS. If no arithmetic is 
required, the RHS may contain either an integer, a string or 
a variable. In that case, either the integer value, the 
actual string or the value of the variable will be assigned 
to the variable on the LHS. 

If the variable on the LHS is not defined, it is 
dynamically defined according to the type and value of the 
RHS. If the variable(s) on the RHS are not defined, an 
error message is printed. If both variables are defined, 
their types are compared to ensure that the assignment is 
correct. 



a. Format 

A LET statement must be in the form: 

'let' <identifier> '=' ( <expression> | <identifier> 

I <number> | <string> ) 

Where rhe word "LET" is the keyword and must be the first 
word in the statement. "LET" is followed by an identifier 
which is treated as the LHS of the statement and will be the 
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recipient of the assignment. Next, the equals sign, " = is 
expected. This is used to separare the LHS from rhe RHS and 
xo show the direction of assignment. It should not be 
confused with the standard relational operator which 

means equality. ( In RSCL equality is represented by the 
string ”eq") . The RHS may contain only one of either an 
expression, an identifier, a number or a string. Up>on 
execution of the let statement, the value of the RHS is 
assigned to the variable on the LHS. 

The expression on the RHS may be a valid arith- 
matic expression containing variables and the arithmetic 
operators of »*•» and These operators hold 

their standard meaning of addition, subtraction, multiplica- 
tion and division. The precedence of operations may be 
either implied or explicitly declared by the use of paren- 
theses. The implied precedence is equals •'/” and "+" 

equals While ”♦'* and “/" are the higher precedence and 

are always performed before or Operations of equal 

precedence are performed left to right. Figure B. 3 illus- 
trates the LET statement format. 

b. Error Types 

The error messages associated with the LET statement are: 
HESSA6E: 

AN IDENTIFIER was expected, but ssss was found 

at 1111. 

EZPLA8ATIOH: 

••ssss" is the token that was found prior to the 
point "1111" in the input line. Check the syntax ,of the 
statement containing this line. 

HESSAGE: 

= was expected, but ssss was found at 1111. 
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EZPLAHATIOH: 



”ssss'* is the token that 
point "1111" in the input line. An 
nating the direction of the valua 
statement. 



was found prior to tha 
"=" was expected iesig- 
assignmenr in the let 



HESSAGE: 



AH ARITHMETIC EXPRESSION was expected, but ssss 
was found at 1111. 

EIPLAHATIOB: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. The RHS of the let state- 
ment did not contain a valid arithmetic expression. Most 
likely a matching parenthesis was omitted. 



HESSAGE: 



AN ARITHMETIC OPERATOR was expected, but ssss 
was found at 1111. 



EXPLANATION: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. Tha RHS of the LET state- 
ment did not contain a valid arithmetic operator between two 
identifiers . 



HESSAGE: 

Ondefined identifier, ssss at pppp in line: 1111 

EXPLANATION; 

"ssss" is the token that was found prior to the 
point "pppp" in the input line "1111". An identifier in the 
RHS of the let statement did not have a value. All identi- 
fiers must be set before they can be referenced. 

MESSAGE: 

Data type mismatch. A string type was expecned 
at pppp in line: 1111 

EXPLANATION: 

The LHS of the LET statement was of type string 
but the RHS was not. 
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let a = 7; 

Assigns the integer value 7 to the variable 
•Ja". If "a” . is undefined it will also dynamically 
declare var-iaole "a” type "I" for integer. 

let a = b; 

Assigns the value of "b" to the variable "a". 

If •' D” does not have a value then an error is 
called. If both '’a** and '•b” have values then 
a type checlc is mads. Otherwise, ”a*' is 
dynamically assigned the data type of "b”. 

let a = ( (b + c) * 7) ; 

Assigns to the variable ''a'' the resulting value of 
the SHS expression. If "a” is an undefined variable 
then It will dynamically receive rhe same data 
type as the expression result or if "a” is defined 
the LHS and RHS types are compared. 

let a = ''this is a tesr” ; 

Assigns the string, "this is a test*', to rhe 
variable "a". If "a" is undefined then it will be 
dynamically assigned data type "S" in the symbol 
table or variable "a" is compared for data type 
"S" string. 



I , j 



Figure B,3 SAMPLE LET STATEMEHTS. 



c. Osage Constraints 

A maximum of 20 operations may be nested in the arithmetic 
expression. The type checking is performed based on the 
type of the right-most variable in the RHS. 

2 . The GST Stat eme nt 

The GET statement is used to read data into the program from 
some external device and assign that data value to a program 
variable. 



a. Format 

A GET statement must be in the form: 
' get* <device> <list> 
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where the word ”GET” is the keyword and must be 
the first word in the statement. "Get” is followed by a 
device. This device may be either '•CRT** for the user's 
console or the name of a file. Anything which is not "CRT" 
is considered a file. The name of the file may optionally 
be prefaced by a disk drive designator and/or suffixed by a 
file type. The total file name follows the file naming 
conventions established for the CP/M operating system. 

Following the device is a list of identifiers 
which will receive the values as read from the input device. 
If the identifiers are already defined, the data will be 
read according to the defined type. Otherwise, the identi- 
fier's type will be set depending on the type of the data 
which is read. Figure B. 4 illustrates the GET statement 
format. 






get CRT a (b ,c. . . ) ; 

Reads the next terminal input and assigns it to 
the variable "a". If the variable "a" is undefined 
it will dynamically assign the input's data type 
to "a". Otherwise, it will perform a type check 
on "a". More then one input can be read from the 
terminal during a get statement. Type checking 
is done on each receiving variable. 

get <FN> a (b ,c. . .) ; 

Opens the designated data file <FN> and reads the 
data in sequential order. The receiving variable (s) 
are either dynamically assigned the input's data 
type (undeclared) or a type check is performed. 



Figure B.4 SAMPLE GET STATEHEHTS. 
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b. Error Types 

The error messages associated with the GET statement are: 
HESSAGE: 

DEVICE * CRT' or a file name was expected, but 
ssss was found at 1111. 

EXPLAHATIOH: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. The word 'get' must be 
followed by the name of the device from which to read the 
data . 

HESSAGE: 

Filename — (<FN> [.<FT>]) -- was expected, but 
ssss was found at 1111. 

EIPLANATION: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. A file name may be up to 8 
characters long and optionally prefaced by a drive desig- 
nator (one character followed by a colon) . 

Filetype — (<P N> [.<FT>]) -- was expected, but 
ssss was found at 1111. 

EZPLANATICN: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. A file type may be up to 3 
characters long and musr be prefaced by a period. A file 
type only appears after a valid file name. 

HESSAGE: 

Unable to open file - check <FN> is capitalized 

EXPLAHATIOH: 

The file designated in the GET statement does 
not exist. Check the spelling of the file name. Be sure to 
watch for discrepancies in capitalization. 
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HESSAGE: 

Cannot read from the list device at pppp in 

line: 1111 
EXPLANATION: 

"PPPP" is the point in the input line "1111" at 
which the error occurred. A device type of "LSI" is illegal 
for the GET statement. 



c. Osage Constraints 



There are no usage constrai 

3* The POT Sta t e men t 

The POT statement is used t 
able to some external devic 

a. Format 

A POT statement must be in 
•put* <device> [’skip*] < 
Where the word "POT" is th 
word in the statement. "PO 
device may be either "CRT" 
the line printer or the nam 
not "CRT" or "LSI" is cons 
file may optionally be pre 
and/or suffixed by a file t 
the file naming convention 
ating system. 

The device is 
•skip*. If included, this 
to be transmitted to the ou 
only done once per statemen 
Next is a list 
strings. Figure B.5 illust 



nts in the GET statement. 



o ouput data from a program vari- 

e. 



the form: 
list> 

e keyword and must be the first 
T" is followed by a device. This 
for the user*s console, "LST" for 

Anything which is 
The name of the 
faced by a disk drive designator 
ype. The total file name follows 
s established for the CP/M oper- 



e of a file, 
idered a fils. 



optionally followed by the word 
will cause a newline control code 
tput device. Note, the skip is 

t. 

of identifiers and/or character 
rates the PUT statement format. 
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put CRT a (b , c. . . ) ; 

Displays on the CRT (screen) the value of the 
variable "a”. Multiple displays (b,c...) are allowed. 

put CRT SKIP (a,b...) ; 

Skips a l^e prior to displaying the variable data. 
The skip 13. performed only once prior to disulaying 
ing the variable (s) value (s). 

put LST a (b , c. . . ) ; 

Toggles the printer on (providing it is turned on) 
ana transfers the variable (s) value (s) to it. 

put LST <FN>; 

Toggles the printer on (providing iz is turned on) 
and transfers the data contained in the designated 
file <FN>. 

put <FN> a (b,c. . .) ; 

Opens the designated file <FN> and stores the 
variable (s) value in the file. The file <FN> is 
automatically closed upon statement termination. 






Figure B.5 SAMPLE POT STATEMEHTS. 



b. Error Types 

The error messages associated with the PUT statement are: 
MESSAGE: 

DEVICE "CRT” or "LST" or a file name was 
expected, but ssss was found at 1111. 

EZPLABATIOH: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. The word 'put' must be 
followed by the name of the device on which the data is to 
be written. 

MESSAGE: 

Filename — (<FN> ( . <FT> ]) -- was expected, but 

ssss was found at 1111. 
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EXPLANATIOH: 



"ssss” is the token that was found prior to the 
point "1111 •' in the input line. A file name may be up to 8 
characters long and optionally prefaced by a drive desig- 
nator (one letter followed by a colon). 

BESSAGE: 

Filetype — (<FN> [.<Fr>]) -- was expected, but 
ssss was found at 1111. 

EXPLAHATION: 

"ssss" is the token that was found prior to the 
point "1111" in the input line. A file type may be up to 3 
characters long and must be prefaced by a period. A file 
type only appears after a valid file name. 

BESSAGE: 

Undefined identifier, ssss at pppp in line: 1111 

EXPLAHATIOH: 

"ssss" is the token that was found prior to the 
point "pppp" in the input line "1111". A value must be 
defined for any variable before it can be output. Be sure 
that all designated variables are sat to some value before 
they are referenced. 

c. Usage Constraints 

If the data is being put to a file, that file is opened in 
append mode. Therefore, if a new file is desired, the user 

must ensure that any previous file with that name is erased 
prior to executing the PUT statement. 

4. The ^ Sta t ement 

The IF statement executes a set of statemenrs based on the 
logical value of the IF clause. If this value is true (not 
0) , the THEN group of statements is executed. If the IF 
clause value is false (0) , the ELSE group of sratements is 
executed. The ELSE group is optional. If it does not exist 



50 



and the IF clause value is false, the entire IF statement is 
ignored. 



a . Fo r m at 

An IF statement must be of the form: 

•if <logical expression> ‘then* <statemenrs> 

Where the word '*IF" is the keyword and must be the first 
word in the statement, mif» is followed by a logical 
expression. This expression must be contained within paren- 
theses and may be any valid combination of logical operators 
(eg. It, gt , ne, le, ge) , logical functions (and, or, not) 
variables and numbers. Precedence of operations is deter- 
mined solely on the bases of parenthetical grouping. 

The logical expression must be followed by the 
word "THEN” and the group of statements which will be 
executed if the logical expression is true. This group of 
statements terminates either with the word "ELSE” or the 
word "ENDIF”. 

If the logical expression is false, the THEN 
group of statements is skipped and the ELSE group is 
executed (if it exists) . The IF statement terminates upon 
detection of the word "ENDIF;”. Figure B.6, illustrates the 
IF statement format. 

b. Error Types 

The error messages associated with the IF statement are; 
BESSAGE: 

An IF statement must have a logical expression 
at pppp in line: 1111 
EXPLAHATIOH: 

"pppp" the point in the input line '•1111" at 
which a logical expression was expected. Check for matching 
parentheses . 
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if <logical expression> then 

<stat ement s> 
else 

<statement s> 
endif ; 

The logical expression portion is tasted first. If 
true, the statements in the THEN portion (any RSCL 
statements^ are executed in ordar. The statements 
contained in the ELSE (optional) portion ara 
executed only when the IP condition returns false. 
The IF statement is terminatad by an ENDIF, 



Figure B.6 S&HPLE IF STATEBEHT. 



BESSAGE: 

THEN was expected but ssss was found at 1111. 

EXPLAHATIOH: 

••ssss'* is the token that was found prior to the 
point "pppp". The THEN clause is mandatory in an IF state- 
ment, Be sure that all dasignatei variables are set before 
thay are referenced. 

BESSAGE: 

ENDIF was expected but ssss was found at 1111. 

EXPLANATION: 

"SSSS" is the token that was found prior to the 
point "pppp". An IF statement must terminate with the word 
"ENDIF". 

c, Osage constraints 

There are no usage constraints for an IF statement. 

5. T he LOOP St atement 

The LOOP statement repeats a set of statements a specified 
number of times. Any number of repetitions may be specified 
via either a number consta nt or a variable entry . 



52 



a . F3 r m at 

A LOOP statement must be in the form: 

'loop' ( <iientifier> | <number> ) <statements> 'endloop;* 
Where the word "LOOP" is the keyword and must be the first 

word in the statement. "LOOP" is followed by either a 

number or an identifier which gives the number of times the 

loop is to be executed. The loop checks this value before 

execution. If the loop value is <= 0, the statements in the 
loop are skipped. Otherwise, the inner statements are 
repeated until the loop counter reaches 0. The loop counter 
cannot be changed once the loop has begun executing. Even 
if the identifer used for the loop counter is altered, the 
loop will not be affected. Figure B.7 illustrates the LOOP 
statement format. 

I 1 



loop a 

<statement s> 
endloop; 

The variable "a" contains the number of 
iterations that the statements contained 
within the loop will be executed. Any 
combination of valid RSCL statements 
is allowed. 

loop 7 

<stat ement s> 
endloop; 

The only difference in this statement is the loop 
counter is in integer form vice identifier form. 
The loop execution sequence is not altered. 



Figure B.7 SAflPLE LOOP STATEHEHT. 
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b. Error Types 



The error messages associated with the LOOP statement are: 



HESS AGE: 

Undefined identifier, ssss at pppp in line: 1111 

EZPLAHATION: 

”ssss” is the token that was found prior to the 
point "pppp** in the input line "1111". A value must be 
defined for any variable before it can 
counter. Be sure that all designated 
before they are referenced. 

HESSAGE: 

An integer or variable loop count was expected 
but ssss was found at 1111 



be used as a loop 
variables are set 



EXPLANATION: 

"ssss" is the token that was found prior to the 
point "1111". A locp counter can only be an integer or an 
identifier. 

c. Usage Constraints 

Nested loops cannot be used. 



6* The CASE S tatement 



The 


CASE 


the 


case 


the 


case 


If 


none 


executed 



statement executes a set of statements based upon 
variable. If one of the cases matches the value of 
variable then that set of statements is executed, 
match, then the OTHERWISE set of statements is 



a . Fo r m at 



The CASE 
' case* 



statement must be in the form: 
<idenrifier> ': ' case_num 

•otherwise:' <statements> 



•endcase* 
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where the word "CASE" is the keyword and must be the first 
word in the statement. "Case" is followed by an identifier 
and a colon. This is the case variable. Each of the cases 
that follow begin with either a number or an identifier 
followed by a colon. This value is compared with the value 
of the case variable. If they are equal, then all the 
statements in the case element (up to the next case number) 
are executed. If no case number matches the case variable 
then the statements in the otherwise clause are executed. 
The CASS statement is terminated with the word "ENDCASE" and 
a semicolon. Figure B.8 illustrates the CASE statement 
format. 



1 



case a: 

b: <statements> 
c: <statements> 

6: <statements> 
otherwise 
endcase; 

The case statement uses a variable or an integer 
to indicate which case element will be invoked. 
The "a" represents the data type of the case 
element index. If none of the case elements are 
invoked then the otherwise case element is 
executed. Any valid RSCL statement is allowed. 



Figure B.8 SAMPLE CASE STATEMENT. 



b. Error Types 

The error messages associated with the CASE statement are: 
MESSAGE: 

Undefined identifier, ssss at pppp in line: 1111 

EIPLABATION: 

" 3 sss" is the token that was found prior to the 
point "pppp" in the input line "1111". A value must be 
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defined for any variable before it can be used as a loop 
counter. Be sure that all designated varialbes are ser 
before they are referenced. 

HESSAGE: 



— : — was expected but ssss was found at pppp. 

EXPLAHATION: 

"ssss” is the token that was found prior to the 
point "pppp". A case variable must be followed by a colon. 
MESSAGE: 



OTHERWISE was expected but ssss was found at 

pppp. 

EZPLABATIGM: 

"ssss" is the token that was found prior to the 
point "pppp". A CASE statement must include an OTHERWISE 
clause to handle the event when no labled case value was 
matched. 



c. Usage Constraints 

There are no usage constraints for the case statements. 



7. The CREATE State ment 

The create function was not coded because the interface 
between the CLI and display modules is unknown. The create 
module was designed to interface with a commercial produce. 
The product is still enroute to the school. When coded the 
create module will assign attribute values to specified 
fields. The resulting template is then utilized for data 
display through the display module. 

8. The DISPLAY Stat ement 

The display function was intended to be an external commer- 
cial product purchased from a local vendor. Unfortunately, 
the supply system was uncooperative and the product never 
arrived. As designed, display manager takes the output data 
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and transposes it onto the requested screen shell created in 
the create module. 

F. GENEBAL ERBOR HANDLING 

The system and syntax error handler messages are formatted 
as follows: 

("♦♦♦♦ SYNTAX or SISTEH ERBOR **♦♦'•) 

(ERROR MESSAGE (S) ) 

MESSAGE: 

Symbol table exceeded. 

EIPLAHATIOH: 

The maximum length of the symbol table was exceeded, too 
many variables in the program. 

MESSAGES: 

Premature end of input encountered. 

EXPLANATION: 

The program ended without a proper terminator i.e. END. 
Program could be in the middle of a command when the input 
terminates. 

MESSAGES: 

Unrecognized character, ssss in line: 1111. 

EXPLANATION: 

"ssss", a non ASCII type token, was encountered prior to 
the point ”1111'' in the input line. 

MESSAGES: 

String length exceeds (132) in line 1111 
EXPLANATION: 

The token prior to the point ”1111” in the input line 
exceeds the maximum sring length of (132). 

MESSAGES: 

PROGRAM was expected, but ssss was found at 1111. 
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EXPLAHATION: 

Program's must start with tha constant "PROGRAM" 
followed by the program name. 

BESSAGES: 

AN IDENTIFIER was expected, but ssss was found at line 

nil. 

EXPLAIITIOH: 

This could have several meanings. LHS's of let state- 
ments require an identifier (variable). Dana file reads also 
require a variable to receive transfered data. 

MESSAGES: 

END. was expected, but ssss was found at line 1111. 
BXPLAHATIOH; 

An input following a statement must be either another 
statement or an (END.). 

MESSAGES: 

No legal Command Language statement was found prior to 
the point im in the input line, 

BXPLAHATICHS; 

This error message is only invoked during the first 
statement following the program name. 

MESSAGES: 

expected at ssss in line 1111. 

EXPLANATION: 

Semicolons terminate all statements. Check the statement 
at the indicated line. 
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A£E£:iCIl c 

PPCGRAM SOURCE CCCE LISTING 



/’*' R St S Command Lanouaqe 

« 



* Last update: 22 Sep 1983 

« 




idef Ine 


debug 


0 


idef ine 


debugcase 


0 


«def Ine 


debudget 


0 


«def Ine 


debuolf 


0 


#def ine 


debuglet 


0 


#de£ine 


debugloop 


0 


#def ine 


debuoput 


0 


#def ine 


debuostate 0 


8def ine 


false 


0 


•define 


true 


1 


•define 


maxsym 


25 


•define 


devslz 


15 


•define 


llneslz 


132 


•define 


lOOP-lSt- 


SiZ 10 


•define 


str Inqslz 


132 


idef ine 


symslz 


10 


•define 


OPtorslz 


20 


•define 


oorandslz 


40 


•define 


EOFTLE 




•define 


NE'-LINE 


'0 


•define 


Id.token 


1 


•define 


str.token 


2 


•define 


Int-token 


3 


•define 


ar Ith.op. 


token 


•define 


loq.op. token 


•define 


loo-f unc- 


token 


•define 


other-token 



/■$***^*-$*** ********* ***************************************^*********** 

* GLOBAL variable DEFINITIONS * 

*/ 



FILE ^output, »input, *source, ♦locp«£lle; 

char LOOP. FILE C20) , »loopptr; /* file name for loop statements*/ 



char sav.dev tdevsiz] ; /* device name for put & get */ 
char put-dev tdevsiz] ; /* device name for put statement*/ 
char qet.dev CdevsizJ ; /* device name for qet statement*/ 
Char symtype; /* type of symbol I or C */ 
char symld [symslz] , *ldptr; /* actual symbol char strino */ 
char string Cstringslz] , *sptr; /* character string */ 
char token Csymslz] , *tptr: /* actual token char string */ 
char line Clinesiz] , *lptr; /* current input line */ 



char looo-lst [loop.lst.slz] [lineslzJ ;/*statements repeated in loop*/ 
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Int loop.cnt; 


/♦ 

/* 


loop statedient counter, used */ 
by getline to repeat staternt*/ 


int token. type; 


/* 


type of token 


*/ 


Int syrrval; 


/♦ 


Value of syrrbol 


*/ 


Int nufTsym; 


/* 


number of symbols active 


*/ 


Int exp-result; 


/* 


result of arlth expressions 


*/ 


Int opr.value; 


/* 


precedence values of arith.oc*/ 


struct < 


/* 


symbol table 


*/ 


char id Csymsiz] , »sldptr; 


/♦ 


symbol name 


»/ 


int value; 


/» 


symbol value 


»/ 


char type; 

> syirbol Cmaxsyrr] , »symptr 


/* 


symbol type (I or C) 


»/ 
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/» 

* This is the fTiain routine for the Coirmand Languaoe Interpreter, 

♦ It calls "stateirents" to process all other statements. 

* If rrain completes successfully the interpreter exits. 

♦ 

* Functions used: error ( 1 1 / 1 2/ 1 4/ 5 1 ) , next, statements 

* Global used; token, token-type 

* Constants used: id. token 

* 

* Author: Dennis J, Ritaldato 

* Last update; 22 Sep 1983 
*/ 

^include <stdio,h> 

«ir. elude "olobai.interp" 
main () 

< 

LOOP-FlLECO] = 

strcpy (LOOP.FILE, "LCCPZZZZ” ) ; 
loco-cnt = 0; 
numsym s o; 

source = f ooen ( "RSCL" , ”r " ) ; 

/* command language program * 

next ( ) ; 

if C strcmpCtoken, "PROGRAM") ) 
error (11); 
next ( ) ; 

if ( token-type 1= id-token ) 
error (12); 
next ( ) ; 

if ( 1 statements ( ) ) 
error (51); 

if ( strcmp(token,"END") ) 
error (14); 
next ( ) ; 

If (tokenCO) Is '.') 

error (14); 
exitO ; 



/* init loop counter */ 
/* init symbol table »/ 
/* open source file for */ 
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/* 

* Statetrents checks the token tc deterirlne if it is a reserveo x'ord 

* Indicatlnq the beairnino of a ccmrand language staterent. 

* If found the corresoondlno functlonis called to process the 

* statement. Then statefrent calls itself to look for irore statements 

* and returns true, 

* Functions used; case«statement , create, display, error(53), 

* if. statement , let-statement, loop-statement, next, 

* put-statement qet-statement , 

» Globals used: token 

* Constants used: none 

* 

* Author: Dennis 0, Rltaldato 

* Last update: 19 Sec 1983 
*/ 

•include <stdlo.h> 

•include "global . Interp" 
statements () 

< 

•if debuostate 

prlntfC* Entered statements with token of %s.O, token); 

•endlf 

if ( 1 strcmp ( token , "LET") ) 

{ nextO; 

let-statement ( ) ; 

} 

else if ( 1 strcmp ( token , "IF") ) 

{ nextO; 

lf-statement( ) ; 

> 

else if ( i strcmp ( token , "PUT") ) 

{ nextO; 

cut-statement ( ) ; 

> 

else if ( IstrcmpCtoken, "GET") ) 

{ nextO; 

qet-statement ( ) ; 

> 

else if ( IstrcmpCtoken, "LCCP") ) 

{ nextO; 

loop-statement O ; 

> 

else if C IstrcmpCtoken, "CASE") ) 

{ nextO; 
case-statementC); 

> 

else if C IstrcmpCtoken, ";") ) 

< nextO; 

#lf debug 

prlntfC" COMMENT found, 0); 
tendif 

while C strcmp C token , ";") ) 
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f 







next ( ) 



> 

else if ( ! strctrc ( token , "DISPLAY") ) 

{ nextO; 
display C) ; 

> 

else If ( J strcnppctoken, "CREATE") ) 

< next ( ) ; 
create ( ) ; 

> 

else 

return(false) ; 
if ( tokentO) 1= ) 

error C53) ; 

nextO; /♦ bypass ; 

statements ( ) ; 
return (true); 



63 



/♦ 

* 

t 

* 

* 

* 

* 

« 

* 

* 



The scanner scans the Input streair for toKens which are either: 



identifiers 
Inteaers 
strings 
logical ops 
arlth CPS 
logical funcs 
others 



alpharalphanurr I . 
digit: Inteaers 
anything except ; 

EO I LT I GT I NE I LE I 
» I - I + I / 

AND I OR I NOT I CON 
any other ASCII character 



GE 



* Functions used: error(4), getllre 

* Globals used; line, Iptr, icg.ocr, log-func, loop^cnt, loop-list# 

* loop-lst-cnt # locc-l s t-ptr # 

* sptr, string, token, token-type, tctr 

* Constants used: ar Ith.op-toker , Id-token, Int-token, symslz, 

* log-op-token , other-token, str-token, 

* IcG-f unc-token 

* Author: Dennis Ritaldato 

* Last update: 22 Sep 1983 
*/ 

#include <ctyDe.h> 

«include <stdlo,h> 

^include "alcbal , Interp" 
next () 

< 

Int 1 = 0; 



tptr = token; 

»tptr = NULL; 
token-type = 0; 

/* it end of line ♦/ 

if ( (»lPtr == NULL) II (♦Iptr == NE'WLINE) ) 

getllneO; /♦ ciet new line */ 

while ( C»lptr == ' ') II ( ilsascll (♦Iptr) ) )/♦ skip blanks */ 

if ( (*lptr == NULL) II (♦ictr == NEWLINE) ) /* it end of line */ 
getllneO; /♦ ciet new line */ 

else 

++lptr ; 

> 

if ( IsalphaCnptr ) ) Is token an identifier? */ 

{ for ( 1 = 0: IsalphaC^lptr) I I lsdlgit(*lptr) II (»lptr == '-'); ) 
if ( 1++ < symsiz ) 

♦tptr++ = upperC lptr++ ); 

*tptr = NULL; 

if ( llog-oprO && !log-func() ) 
token-type = id-token; 
return; 

} 

else if ( lsdiglt(*lptr) ) /* Is token an Integer? */ 

{ while ( isdigitC»lPtr) ) 

♦ tptr+-*> = »lptr+-*-; 
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♦tptr = NULL; 
tcicen.tyoe = lnt-to>cen; 
return ; 

> 

switch (*lptr) { 

case'"': /♦Istokenacharstrlnq?^/ 

sptr = string; 
tcken«type = str-token; 

++lptr ; 

for Ci=0; (<lptr != ++iptr) 

< If C ♦Iptr == NULL ) /♦ if end of line */ 

getllnec); /*getnewllne»/ 

if (1++ < strlngsiz) 

♦sptr++ = flptr; 
else 

error (5) ; 

> 



++lptr; /* bypass second " */ 

»sptr = NULL; 

return; 

case ' + case /♦ is token an arlth.-netic op?*/ 

oor-value = l; 

token. type = arith-op.token ; 

*tptr++ = *lptr++; 

♦tctr = NULL; 



return; 

case case '/': 

oor. value = 2; 

token. type = arith.op.toker ; 
♦tPtr++ = *lptr++; 

*tptr = NULL; 



return; 



case 




case 




case 


'C' 


case 


'3 ' 


case 




case 




case 


• 


case 


f 


case 


» 1 ' . 
• • 


case 


'fl ' : 


case 


'# ' 


case 


'S' 


case 




case 


# A # • 
• 


case 


'&' 


case 


0—0 


case 




case 




case 


# # 

9 


case 


0 0 
• 


case 


• • 


case 


#7 # j 


case 


' 1 ' 


case 




case 


^ m * 5 


case 


# ' # • 
• 


case 


# # # 







token. type = other. token; 
*tptr++ = »lptr+>«-; 

*tptr = NULL; 



return; 
default : 

/♦error (4) ; */ 

#if debug 

prlntf ( "--Unrecognized char %c with value 
»endif 



/*ls token another symbol?*/ 



%d found. 0, *lptr ,*lptr) ; 



*lptr++; 
next ( ) ; 
return; 

> /* end switch ♦/ 
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/* «nd next */ 
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/♦ 

* Getllne reads the next lire either from the Incut stream 

* If the loop counter loop_crt" is 0 or from the loop statement 

* list, "looD«lst" If the loop counter is oreater t^^an 0, It 

* decrements the loop counter each time a line is read, 

* Fach line read, regardless of source is Placed into an array of 

* characters called "line'*. 

* If an ECFILE Is encountered an error message is printed out and 

* the orooram terminates, 

* Otherwise, the line pointer Is reset to the bealnnlnq of the 

* line and the function returns, 

* 

* Functions used: errorO) 

* Glcfcals used; line, Iptr, loop.cnt, loop-list, looc-lst-cnt , 

* loop-lst-ptr 

* Constants used: ar Ith-OD-token , Id-toxen, int-to^’en, 

* loq-f unc-toker 

* 

* Author: Dennis Rltaldato 

* Last update: 22 Sep 1983 
*/ 

oetlineO /* begin getllne */ 

< 

1 n t 1 ; 

for (1=0; 1 < llneslz; 1++) /* clear line buffer */ 

linetl] = null; 

If ( looD-cnt > 0 ) /♦ read from the loop list? */ 

{ 

If ( fqetsCllne, llneslz, locp-flle) == EOFILE ) 

< fclose( loop-file) ; 

If C--loop-cnt > 0 ) 

( loop-file = fopen (LOOP-FILE, "r"); 
f gets (line, llneslz, loop-file) ; 

> 

} 

iptr = line; 
return; 

} 

else If ( source != NULL ) 

( if( fgetsdlne, llneslz, source) == EOFILE )/*read from file RSCL*/ 
error (3) ; 

#if debug 

prlntf ("--Source line read.O); 

#endlf 

else 

( If ( gets(llne) == EOFILE ) /♦ read from the terminal */ 

error(3); 
flf debug 

printf("— CRT line read.O); 
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#endif 

> 

#lf debug 

pr Intf ( "--The new line is: %sO,llne); 

#endif 

Iptr = line; 
return; 

> /* end getllne ♦/ 
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/* 

* Upper converts a lower case ASCII character to upper case ascii. 

* Any characters which are net lower case ASCII are Iqnored. 

« 

* Author: Dennis J. Ritaldato 

* Last update; 14 Sep 1983 
*/ 

upper CO 
char *c; 

{ 

if ( ('a' <= »c) && (»c <= 'z') ) /* if lowercase */ 

*c = *c * 'A' - 'a'; /* convert to uppercase*/ 

return ( *c ) .* 
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* Log.opr examines the current token to determine If It is 

* logical operator, 

* If so, it sets the token.type acpropr lately . 

* 



♦ Author: Dennis J, Rltaldato 

* Last update; 15 Sep 1983 
»/ 



loo. opr ( ) 

{ 

if C strlen(token) 1= 2) 
return(false) ; 
tptr = token; 
switch C*tntr) < 
case 'F.'; 

if C*++tptr != 'Q') 
return(false) ; 
break ; 
case 'N'; 

if (t++tptr 1= 'E') 
return (false ) ; 
break ; 

case 'G': case *l*i 

If ( C*++tptr 1= 'X') && (♦++tptr 
return(false) ; 
break; 
default ; 

return(false) ; 

} 

token.tyoe = loo. op. token ; 
return(true) ; 



/* begin log.opr 



!= 'E') ) 



/♦ end log.opr 



a 



*/ 



*/ 
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/» 

♦ Loq.func examines the current tcxen to determine if it is 

♦ logical function operator, 

♦ If so, it sets the token.tyce appropriately. 

« 

♦ Author: Dennis J, Ritaldato 

♦ Last update: 14 Sep 1983 
*/ 

lOQ-funcC) /♦ beoin loo.func 

if ( ( Istrcmpctoken, "AND”) ) II (! strcmp ( token , "OR ") ) 

II ( Istrcmpctoken, "NOT" ) ) II ( i strcmp ( token , "CON ”) ) ) 

{ token-type = log-f unc-token ; 
return C true ) ; 

} 

return(false) ; 



> 



/♦ end loQ-func 







i 

i 

a: 



/♦ 

* This procedure adds a new syirbol to the symbol table. 

* Increments numsym 

* creates a new symbol table entry with the values contained in 

* symld, symval and symtype 

* return 

* Author; Dennis J, Rltaldato 

* Last update: 13 Sep 1983 
*/ . 

•Include <stdio.h> 

•include “global , inter?" 
addsym C ) 

< 

int i? 

if (numsym > maxsyir) 
e r r 0 r ( 2 ) ; 

symptr = Ssymool Cnumsym++] ; 
for (1=0; symldC13!=' ++i) < 
symptr -> Idd] = symidCl]; 

syrotr -> value = symval; 

symctr -> type = symtype; > 

#if debug 

prlntf ("ADDSYM entered. Numsym = %d0, numsym); 

•endlf 
return ; 
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# 








/* 

* TMs procedure assigns the value contained In symval to the 

* symbol indicated by symptr. 

* Author: Dennis J. Ritaldato 

* Last update: 13 Sep 1983 
*/ 

#.lnclude <stdlo.h> 

#irclude "global . interp" 
setvalue ( ) 

< 

syirptr -> value = syitval; 
return; 
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/♦ 

* LOOKUP searches the symbol table for a match on symid and 

* syirbol.ld. If found, 

* set symptr, syirval and syirtype from the contents of the 

* symbol table, return true 

* else 

* symptr, symval and symtype remain unchanqed 

* returns false 

* Author; Dennis Rtialdato 

* Last update: 13 Sep 1983 

* / 

tlnclude <stdlo,h> 

♦include "global , interp” 
lockup ( ) 

{ 

Int 1 ; 

for (symptr = StsymbolCO]; symptr <= (symbol + numsym); + + symptr) 
for (1=0; syrrptr->ld Cl] == symidd]; ++1) 
if (symidCll 3= ' < 

symval s symctr->value? 
symtype = syrpptr»>tyce; 
return (true); } 
return (false); 
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< 





i,.; 



/* 

♦This function assiones values to variables. The LHS (left hand side) 

* variable must be an Identifier. The only exception Is when a string 

* Is assigned then the LHS variable Is the global array string, RHS's 

* can be either an expression. Inteoer or a declared identifier *'ith 

* a value of the Identifier stored In the synbol table. Expressions. 

* of any length are accepted. Unary irlnus operations are not 

* supported In this version, 

* 

♦ Functions used; addsyrr .error ( 1 2/ 18/55/57 ) , expression, lookup, next 

♦ setvalue 

♦ Globals used: exp. result, synld. symtype. syrTval. token, token.type 

♦ Constants used; id. token. Int. token 

♦ 

* Author; David J. Siranla 

* Last Update 22 Sep 83 
♦ / 

oinclude <stdio,h> /* Link standard I/C */ 

♦ include •’global , interp" /♦ link all program constants */ 



char operator Coptorsiz] ; /* Declare let. statement variables ♦/ 

char savetyoe; 

int operand Coprandslz] ; 

int a. b.m.n. marker .last. prec; 



let. statement C) 

{ /* Entering let statement ♦/ 

char savetoken Csymslz] ; /* Declare local variables */ 

int sav. value. addf lag; 



#lf debug 

prlntf ('•LET.STATEMEMT entered. 0 ) .* 

♦endlf 

/4^t***t***t***t***t* EVALUATE LEFT HAND SIDE 



If (token.type J= id. token) /» Check for identifier */ 

{ 

error (12); /* Error token not identifier */ 

return; 

> 

else 

strcpyCsavetoken. token) ; /♦ Save token name */ 

next (); 

if (strcmoCtoken. "=") == 0) /♦ Check for = token */ 

next C); 

else 

{ 

error(l8); /* Missing operator ♦/ 

return; 

} 
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* The expression function first deterinlnes If the RHS is an 

* expression. If so, then It evaluates the expression and 

* returns the result to exp.result, Error checklno Is cerfcrned 

* throuhqout the function. 

»/ 



if (expression ()) 

sav.value = exp. result; 
else 

if (token. type == id. token) 

< 

strcpy(syit'ld, token); 
if (lookup ()) 

{ 

sav.value = sytuvai; 
savetype = syfutyce; 

} 

else 

error (55); 
next (); 

> 

else 

if (token, type == int. token) 

{ 

savetype = 'I'; 
sav.value = atoi(token); 
next ( ) ; 

> 

else 

if (token. type == str. token) 
{ 

symtyoe = 'S'; 
next ( ) ; 

strcoy(symld,savetoken); 
if (I lookup ()) 

< 

symval = 0; 
addsym (); 
return; 

> 

if (symtype == 'S') 
return; 
error (57); 
return; 

> 

else 

{ 

error (24) ; 
return; 



/♦ Check for 2nd aro = expression »/ 



/♦ Exp result saved */ 

/♦ Load symid for lookup */ 

/* Save variable value */ 

/* Save variable type */ 



/* Varlapie not in symbol table */ 



/♦ Save Inteqer value */ 



/* Not exp, strlnq, id, int */ 
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STRCFY CHECK 



strcpy ( symld , savetoken ) ; /» Lead symld for lookup */ 

if (lookuD ()) 

If (savetype =s syrrtype) 

{ 

symval = sav-value; 

setvalue (); /♦ Assign values to syir.bol table variables*/ 

> 

else 

error (57); /♦ Variable not in symbol table */ 

else 

< 

symval = sav«value; 
symtype = savetype; 

addsym (); /* Add a ne’* variable to symbol table*/ 

> 

> 
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EXPRESSICN FUNCTION 






* EXPRESSION determines If the tc!<er is a valid arithmetic 

* expression. An arithmetic expression is defined as a term 

* optionally followed by a arithmetic operator and a sucexpression, 

* A term is either an expression, an identifier, a number or a 

* strlno, A subexpreslon is a term optionally followed by an 

* operator and a subexpression, 

* If a valid expression is found, it's value is stored in the 

* variable "exp. result” and true is returned. Otherwise false is 

* returned, 

* 

* Functions used: error ( 22/50 ) , lookup, next, pop, pushocratot, 

* pushidoperand , set.prec 

* Globals used: exp. result, symld, symtyoe, symval, token, token. type 

* Constants used: ar ith.oo.token , id. token, int. token 

* 

* Author: David J, Srranla 

* Last Update 22 Sep 83 
*/ 

expression (5 
{ 

m = 0 ; 
n = 0 ; 

last-prec = 0; 

if C (strctro(token , ” ( " ) == 0)) /* Check for lead of exp */ 

{ 

pushoprator (); /'* Push on stack */ 

next (); 

if (token-type == int. token) /* Check for inteoer RHS */ 

savetype = 'I'; 
else 

if (token-type == id. token) /* Check for identifier RHS »/ 

{ 

5trcpy(symld,token) ; 
if (lookup ()) 
savetype = sytrtyoe; 
else 

savetype = 'C'? 

> 

LOOP THROUGH RHS ******************************/ 

while (tokenCO) != ';') /* Loop until is read »/ 

{ 

if ( strcmo ( token ," C ) == 0) 

{ 

pushoprator (); 
nexto; 
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> 

else 

If (strci'pctoKen,”)") == 0) Enter pop routines */ 

{ 

OOP (); 

set.prec (); 
next O; 

> 

else 

If (tcken.type == Id.token) /♦ Lookuo Identifiers */ 

{ 

strcpyCsY"' id, token); 

If (I lookup ()) 
error (55); 
else 
< 

pushidoperand (); 
next (); 

> 

> 

else 

if Ctoken.type =* Int-tcken) /♦ Push Integer tokens 
( 

symval = atoiCtoken); 
oushintoperand (); 
next (); 

> 

else 

/♦ Check operator precedence */ 
If (token. type »= ar 1th. op. token ) 
if (check. pri ()) 

( 

pushoprator ( ) ; 
next (); 

> 

else 

( 

pop (); 
set.prec (); 

> 

else 

error (21); 



END while loop ***■****************■$********■$/ 



if ((operatorCO] = '(') && (operatorCl) = ')')) 
{ 

exp. result = operand C«-(rt] ; 
sytrval = exp. result; 
return (true); 

> 
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else 

error ( 223 ; 

> 

else 

return (false); 



} 
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/t*tt******t^^***** PUSH INTEGER FUNCTION 

/» 

♦ This function pushes the Ipcotrrrlpa Integer token onto the stack 

* operand [ns] . 

« 

* Author? David J, Sirania 

♦ Last Updata 25 September 83 
*/ 



pushlntoperand () 
{ 



operandCrn] = atoi(token); 

++.T1 ; 

} 

/t***^**^t***if*^lii**lf** PUSH IDENTIFIER FUNCTION 

/♦ 

* This function pushes the identifier value operands onto the 

* stack cperard In'] , 

* 

* Author: David J, Siranla 

♦ Last Updata 24 Septerrber 83 
*/ 



pushidoperand C) 
{ 



operandCp] = symval; 

+ + m ; 

> 

/■$^-$*******^******* PUSH OPERATOR FUNCTION ♦♦♦♦♦♦♦♦»♦♦♦»♦***♦♦*♦»♦♦»/ 
/* 

* This function pushes the Incoirping operator onto the stack 
» operator [n] . 

* 

* Author: David J, Smania 

* Last Updata 23 Sectentber 83 
*/ 



pushoprator () 

< 



operatorCn] a tokenCO]? 
++n? 
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/:f*^1^t*****t******* CHECK PRIORITY FUNCTION ♦♦*»*♦♦»*»♦**♦♦*♦»♦♦»*»/ 
/» 

* Check the Incomlno operator prececdence with the existlno hinhest 

* precedence, last.orec, value. Modify if incorrmlrq is qreater. 

« 

* Author; David J, Siranial 

* Last Update 23 Septerpber 83 

*/ 

check. pri () 

{ 



if (opr. value > last.prec) 

{ 

last.prec * opr. value; 
marker = n; 
return (true); 

> 

else 

if (oor. value == last.prec) 
return(true) ; 

else 

return (false); 

> 
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:«««««««« P 0 P function 



. zt*-t.*x*.*tx**^x*x/ 



/» 



* Pec ti^:e operators and operands off tnelr respective stacics 

* accordlno to tne tc'<en read. 



* Author; David J. S.T.arla 

* Last Update 23 Secterrber S3 

♦ / 



PCD () 

■ < 

int l,dcne; 
done = 0; 



if (strcfT,p(to'<en,")") == 0) /» Fop until is found */ 



■*hile (operatcrCn] != '(') 

{ 

-•.ri ; 

a = operand Cn]; 

m m • 

b = operand CfiJ 7 
checic.tcXen (); 

> 

else 

>‘hlle (n >s warxer) /* ?cc until lower precedence »/ 

{ 

• • iT5 * 

a = operand CiTl 7 

• ■ rr. ; 

b = operand [t ] 7 
check. tcxen (); 

> 

return; 

> 
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/:$lf4:$*lf**4**'*innf******** SET PRECEDENCE **************^f*********** 

/♦ 

* Set the precedence variable last»prec to the hlqhest precedence 
» operator In the stack oceratcrCn]. 

* Aothor; David J, Sirania 

* Last Update 23 Secten<ber 83 
*/ 



set.prec () 

int l,done; 

done = 0; 

+ + n; 

cperatorCn] s tokentO]; 

for Ci=0; C(i<=n) && (idone) && CoperatorCi] 1= ')')); i++) 

{ 

if (CoperatorCi] == II (operatorCi] == 

< 

last.prec = 1; 
done = true; 
fparker = 1; 

} 

else 

last.prec = 0; 

> 

return; 

> 

FERFCRI« ARITHMETIC 4********-$******t*******-** / 

/* 

* Perform arithmetic operations based on operatorCn] found. Store 

* results in operandtm], 

* 

♦ Author; David J, Smania 

♦ Last Update 23 September 83 
*/ 



check-token O 

< 

if (ooeratorCnJ == '+') 

< 

ooerandCtr] = (a ♦ b); 
++rr; 

--n; 

} 

else 

if (operatorCn] == 

{ 

operandCir) = (b - a); 
++m ; 

--n ; 



I 
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> 

else 

if CoperatorCn] == '*') 

< 

ODerand[fT] = (a * b); 

+ + fT ; 

--n; 

> 

else 

if CoperatorCn] == '/') 

{ 

operandtir] = (b / a); 
+ + IT ; 

--n; 

> 

return; 

} 



END LET. STATEMENT 
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* This procedure receives data frctr either the screen (CRT) or a 

* resident file. The function first checi<s for the user's recuested 

* display device then responds to the user's data reauests. T-*o 

* types of data inout requests are available to the user: from a 

* file on the user's disk; or a variable stored In the symbie table, 

* Global variable sav«dev stores the user's device recuest, 

« 

Function used: next, error (20/56 ) , device, id.llst, addsyrr 



* Glcbals used: sav-dev, get.dev, 

input 

* Constants used: NULL, stringsiz 

* 

* Author: havld J, S mania 

* Last Update 22 Sep 83 
♦ / 

#lnclude <stdio.h> 

•include <ctyoe.h> 

•include "global. interp” 

char savetype; 

Int sav.val; 

get-statement C) 

{ 

int had; 

•if debug 

or Intf ("GET-STATEMENT entered.O) ; 
•endlf 

if (i deviceO) 

{ 

error ( 20 ) ; 
return; 

> 

strcpy(aet-dev,sav-dev) ; 
if (strcmp(get-dev, "CRT") ==0) 

( while (id-list () ) 

{ 

if (savetype == 'S') 
gets ( string ); 
else if (savetype == 'I') 

scanf (" %d" ,&symval) ; 
setvalue (); 

> 

else if (savetvpe == 'C') 

symval = qetcharO; 
setvalue ( ) ; 

else 



string, sptr, symtype, synrval. 



/* Link standard I/O •/ 

/* Link integer check routine »/ 
/* Link all program canstants */ 

/♦ Declare local variables */ 

/* Entering get statement */ 

/* Declare get variables >•/ 

/» Check for device token ♦/ 

/» Invalid device type */ 



/* Save device name in get-dev*/ 
/» Loop until id-list is empty*/ 
/* Check saved token type »/ 



/* Identifier is unknown »/ 
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*. ■ 



•j 



* 

i 




gets ( str Ina ) ; 
sptr = string; 



for (ba<i = false; C (*sptr 1= NULL) && (*SDtr != ' ') 

s& (Ibad) ); ++sptr) 

If ( ! lsdlqit(*sptr) ) /* Is input a digit 

bad = true; 
if Cibad) 

{ synitype = 'I'; 

svmval = atoKstrina) ; 

> 

else 

< if (strlen(strinq) == 1) 

{ symtype = 'C'; 
sypval = tokenCOJ; 

> 

else 

syptyoe = 'S'; 

> 

addsyrti ( ) ; 

> 

next (); /♦ bypass input variable 

> /»endofwMieloop 

} 



else 

if (strciPPCget.dev, "LST" ) ==0) 

< error(56); /» Invalid device input 

return ( false) ; 

> 



♦ / 



*/ 

*/ 



»/ 



else 

{ input = fopenCqet,dev,"r") ; /* Open file to read only */ 

while (Id.llst () ) /* LOOP until Id.llst is empty */ 

{ 

if ( savetype == 'S') 

fgets ( string, strlngslz, input ); 
else if (savetype == 'I') 

< fscanf (Input," %d" ,&symval) ; 
setvalue ( ) ; 

) 

else if (savetype == 'C') 

{ fscanf (incut," %c" ,&symval) ; 
setvalue( ) ; 

> 



else /♦ identifier is unknown */ 

{ 

fscanf (input," %s", string); 
sptr = string; 



for (bad=f alse; ( (*sptr 1= NULL) && (»sptr i= ' ') 

&& ( Ibad) ) ; + + sptr) 

if ( I isdiglt ( wsotr ) ) /♦ Is input a digit? ♦/ 
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true; 



bad = 
if (Ibad) 

{ SYfftyce = 'I'? 

syrrval = atol ( String ) ; 

} 

else 

< if (strlenCstring) == ID 
{ syintype = 'C'; 
symval = toKen CO] ; 

> 

else 

symtype = 'S'; 

> 



addsynn ( ) ; 
} 

next (); 


/♦ 


bypass 


input variable 


*/ 


> 


/♦ 


end of 


while loop 


*/ 


} 


/* 


end of 


file processing 


*/ 



«1£ debugqet 

print£("At end of GET, token = %s0, token); 

#endif 

return; 

} /* end get.statement */ 
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ID. LIST FUNCTION 



/♦ 

* The Id. list function checks if the input variable is already 

* declared in the syfrbol table. If true, it saves the data type for 

* type checking, A data tyce of 'U' undefined is set otherwise, 

* Function used: lookup 

* Globals used; syintyce, token 

* Constants used: id. token 

« 

* Author: David J, Srnania 

» Last update: 22 Sep,, 1983 
♦ / 

id. list n 
{ 

if (token.type J= id. token) 
returnCfalse) ; 

strcpyCsymld, token) ; /♦ Place token in symid for lookup check*/ 

if ( lookup ()) 

savetype a symtype; /* Save token type for latter coirpar ison*/ 

else 

savetype = 
return (true); 



/tt*^t******1f**** END GET. STATEMENT 
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/♦ 

* PUT. STATEMENT outputs to either the screen (CRT) 

* or the printer (LSI) data stored In a variable a 

* string or a file. The function first checks for the 

* appropriate display "device" then responds to the 

* users data requests. Two types cf data requests 

* are available: a variable stored in the symbol table; 

* or a string. Global variables put. dev, symval and 

* savetype store the device name, the token value and 

* token type respectively, 

» 

* Functions used; next, error(25), list, device, 

* Glotals used: outcut, put. dev, sav.dev, string, 

* token, token. type 

* Constants used: none 

* 

* Author: David J, Smanla 

* Last Update 22 Sep 83 

*/ 



# Include <stdio,h> /♦ Standard I/C link ♦/ 

•include "global , Interp" /♦ Link all program canstants */ 



char savetype; /* Declare local variables */ 

int sav.val; 



put. statement () /* Entering put case statement */ 

{ 

•if debug 

prlntf ("PUT-STATEMENT entered. 0) ; 

•endif 

if (I devlceO) /* Check for device token */ 

{ 

error(25); /♦ Invalid device type */ 

return; 

> 

strcpy (Dut-dev , sav.dev) ; /* Save device name */ 

if (strcmp(put.dev, "CRT" ) ==0) 

{ if ( istrcmp(tcken,"SKIP") )/* Skip a line */ 

< printf("0); 

nextO; /* bypass skip ♦/ 

> 

while (list ()) /* Loop until list Is terminated*/ 

( 

#lf debugput 

prlntf ( "--List returned true with token = %s0, token); 

•endif 

If (savetype == 'S') /* Checks for token type */ 

puts (string) ; 
else 

If (savetype == 'I') 
printf("%d ", sav.val); 
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else 

Drlntf(”%c "#sav«val); 
next (); 

> /* end while list */ 

> /♦ end if CPT «/ 

else 

if ( strcirp (put.dev , "LST" ) = = 0) 
while (list ()) 

{ 

printf ( "toqplinq nrinterO); 
next C); 

} 

else 

/* Open file with 'a' attribute*/ 
output = f open ( put-dev , "a " ) ; 

#if debuoput 

printf ( "Openinq new file %s0 , put.dev ) ; 

#endif 

if ( J strcrrpctoken, "SKIP") )/* Skip a line in the file */ 

< prlntf("0); 

nextO; /* bypass SKIP */ 

> 

while (list ()) /* Loop until list empty */ 

( 

if (savetype == 'S') /* Checks for token type */ 

fputs (string, out put); 
else 

if (savetype == 'I') 

fprintf (output , "%d ",sav.val); 
else 

fcrlntf(output,"%c ",sav.val); 
next (); 

} 

fclose(output) ; /* Close data file */ 

> 

#if debugput 

printf("At end of put, token = %s0, token); 

#endi£ 

return; 

} 
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/» 

♦ The list function checks fcr the cutPut token suprlied by 

* the user. The ccrresoondlng token data values are stored 

♦ acoropr lately for later cotparlscn. 

* 

* Functions used: next, error(55), lookup 

* Globals used: string, sytrld, syirval, symtyoe, token 

* Constants used: Id, token, Int. token, str-token 

* 

* Author: David J, Sitanla 

♦ Last Update 22 Sep 83 
*/ 

list () 

{ 

if Ctoken_type == Int, token) 

{ 

sav,val = atoi(token); /* Save token value */ 

savetype = 'I'; /* Save token type */ 

return (true); 

> 

if (token, type == id, token) 

< 

/* Place token in sytnid for lookup check */ 
strcpy ( sym id , token ) ; 
if ( lookup ()) 

( 

/* Save token type for later comparr ison */ 
savetype ~ sytrtyne; 

sav,val = syirval; /* Save variable value */ 

return (true); 

} 

error (55); /♦ Unidentified variable */ 

return (false); 

} 

if (token, type == str, token) 

< 

savetype = 'S'; 
return (true); 

> 

return (false); /♦ Error no match */ 

> /♦ end list »/ 

/♦*»»»*»f!|;**^»****END PUT,STATEMENT** ***♦*♦♦»♦♦♦♦♦♦♦*»»♦♦♦**♦*♦♦♦ *=►»»/ 
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/* 

* DEVICE deterirlnes if the current toKen Is a valid 

* I/C device name, A valid device is defined as either 

* "CRT" for the user's console, "LST" for the line printer 

* or a filenaire. The file narre is structured acccrdlno 

* to the file narrina conventions of the CPM operatinn 

* system. That is, a name optionally oreceeded by a one 

* character disK drive desiqnatcr with a colon and 

* optionally followed by a oeriod with a three character 

* file type, 

* If a valid device is found, it is stored in the 

* variable "sav.dev" and true is returned. Otherwise, 

* false is returned. 

» 

* Functions used; next, error(26/30) 

* Glcbals used; sav.dev, to!<en, tcKen.type 

* Constants used; id, token 

* 

» Author; David J, Smania 
* Last Update 22 Sec 83 
♦ / 

linclude <stdio,h> 

^include "qlobai , interp" /* Link all program canstants */ 

function 



device () 
{ 



#lf debug 

prlntf ("DEVICE entered, 0); 
#erdlf 



if (token-type != id-token) 
return (false); 
if ( (strcmp(token, "CRT") == 
< 

tlf debuqput 

printf ( "--device = %s0, token); 
tendif 

strcpy(sav-dev, token); 
next (); 
return (true); 



0) II (strcmp(token,"LST") *= 



/♦ Save display type ♦/ 

/* bypass CRT I LST ♦/ 



strcpy(sav-dev, token) ; 

next (); /♦ bypass fnarre I drive */ 

It ( strcmp ( token ,";" ) ==0) 

( 

streat ( sav-dev , token ) ; 

next (); /* bypass ; 

if (token-type 1= id, token) 
return (false); 
streat ( sav-dev , token); 



0 )) 



*/ 
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next (); /* tycass fname 

} 

If ( strcmp ( token ) ==0) 

{ 

strcatCsav. dev, token); 

next (); /♦ bypass , 

If (token. type 1= Id.tcken) 
return (false); 
strcat(sav. dev, token) ; 

next (); /* bypass ftype */ 

> 

return (true); 



/t*******-^***************** END DEVICE ***********************/ 
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/* IF STATEMENT executes a set of staterrents based on tne 

* logical value of the the IF-clause. If this value Is 

* true (not 0), the THEN-oroup of statements is executed, 

* If the TF-clause value Is false (0), the ELSE-grouo of 

* statements Is executed, 

* The ELSE-qrcup Is optional. If It does not does not 

* exist, the entire IF statement Is skipoed, 

* 

* Functions used: next, error ( 16/17/27/54) , statements 

* Globals used: token, token, type, symld, symval 

* Constants used: symsiz, log,op. token , loc,func. token 

* 

♦ Author: Dennis J, Rltaldato 

* Last update: 22 Sep 1993 
*/ 

#lnclude <stdlo.h> 

Alrclude "global, Interp" 

Int log-result » 0; 

Int term = 0; 
int sub = 0; 

#if debuglf 
int level = 0; 

#er.dif 

If, statement () 

( 

ft if debug 

printf ("IF-STATEMENT entered. 0): 

I endif 

if Cl log-exp() ) 

( error(54); 
return: 

} 

#if debuglf 

printf ( "--log-result at level %d is %d , 0 , level , log, result ) ; 
iendif 

if (log-result) 

{ if ( strcmp(token,"THEN") ) 

( error(l6): 
return; 

} 

•if debuglf 

printf ( "--THEN found, 0); 
iendlf 

nextO; /* bypass THEN */ 

statements C ) ; /♦ execute then clause */ 

/* ski? else clause */ 

while ( strcmpCtoken, "ENDIF") ) next(); 

) 

else 

/♦ skip then clause */ 

< while ( strcmp ( token , "ELSE" ) ) nextC); 

#if debuglf 
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prlntf ( "--ELSE found, 0); 

#endl£ 

rextO; /* bypass ELSE 

statements () ; /♦ execute else clause */ 

} 

If ( strcmp(token,"ENDIF") ) 

< errorCl?); 
return; 

} 



next ( ) ; 




bypass ENDIF 


»/ 


return; 








> 


/* 


end If.statement 


*/ 
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/* 

* LCG-tXP determines If the current tcken is a logical 

* expression, a logical expression is defined as a 

* logical term, optionally followed by both a logical 

* operator and a logical subexpression. The entire 

* logical exoression must be enclosed in parentheses. 

* If a logical expression is found, it's value is 

* stored in the variable "loo-result" and true is 

* returned. Otherwise, false is returned, 

» 

» Author: Dennis J, Rltaldato 

* Last update: 22 Sep 1983 
»/ 

log-exp ( ) 

int ihs = 0, rhs = 0; 
char operator Csymslz] ; 

#if debuglf 

prlntf ( "Entered loo-exp.O); 
tendlf 

if ( strcmp ( toKen , " C " D ) 
returnf false) ; 

nextO: /♦ bypass "C" */ 

ilf debuoif 

prlntf ( "----Left paren found for Level %d. ”»ievel++); 

prlntf(" New token is %s0, token); 

tendlf 

if ( ! loq-term() ) 
returnCfalse) ; 
tlf debuglf 

pr Intf ( "----In loo-exp, log-term returned %d ",term); 

printfC" with token %s.0, token); 

prlntf C "----and token-type of %d, 0, token-type) ; 

tendlf 

Ihs = term; 

if ( (token-type == log-op-tcken) 

II (token-type == loo-f unc-token ) ) 

( strcpy (operator , token ) ; 

nextO; /* bypass operator */ 

ilf debuglf 

prlntf ( "----Logical expreesslon operator, %s, found , 0 , operator ) ; 
iendlf 

if ( ! sub-loq() ) 
return(false) ; 
rhs = sub; 

log-result s compute ( Ihs # operator , rhs ) ; 

»lf debualf 

prlntf ( "----Compute returned %d, 0, log-result) ; 
tendlf 

if ( 1 strcmp ( token ,")" ) ) 

{ nextO; /* bypass ")" */ 
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41f debugif 

prlntf ( ”--Right paren for level %d compound expression . 0 , level) ; 
printf ( "--With next tolcen of %s . C , token ) ; 

•endlf 

return (true ) ; 

> 

else /* matching right paren not found »/ 

{ e r r 0 r ( 27 ) ? 
return (false ) ; 

> 

) 

else If C I strcmp ( token , " ) ” ) ) 

{ loQ.result = Ihs; 

next()j /♦ bypass " ) " */ 

returnCtrue ) : 

> 

else /* matching right paren not found ♦/ 

error (27) ; 
return (false) ; 

} /* end log.exp */ 
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/* 

♦ SUB. LOG deterrpines If Che current token is a logical 

♦ subexpression, a sub expression is defined as a 

♦ logical terp, ontlonally followed by a logical operator 

♦ followed by either a logical subexpression or a 

♦ logical expression. 

♦ If a logical subexpression is found, It's value is 

♦ stored in the variable "sub" and true Is returned, 

♦ Otherwise, false is returned, 

*/ 

sub. log ( ) 

< 

Int ihs = 0, rhs = 0; 
char operator tsyirslz] ; 

Ilf debugif 

prlntf ( "Entered sub. log, 0); 
lendlf 

If ( ! log.termc) ) 
return! false) ; 

Ihs = term? 

If ( (token. type i= log. op. token) 

&& (token. type != loq.f unc. token ) ) 

( sub = Ihs; 
return(true) ; 

> 

strcpy ( operator , token ) ; 

nextO; /♦ bypass operator */ 

if ( sub. logo ) 

( rhs = sub; 

sub = corrpute ( Ihs , operator , rhs ) ; 

Ilf debugif 

prlntf ( "----In sub. log, sub. log returned %d.0,sub); 
lendlf 

return (true); 

> 

if ( log.expO ) 

< rhs = log. result; 

Ilf debugif 

pr Intf ( "----In sub. log, log. exp returned %d,0,rhs); 
lendlf 

sub = coffpute ( Ihs , operator , rhs ) ; 
return (true); 

} 

return (false); 

1 / 



> 



/* end sub. log 
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/♦ LOG-TERM deterrnines if the current token Is a terfr 

♦ In a logical expression. A tern- is defined as a 

* logical expression, an identifier or a number. 

* If a term is found, it's value is Placed in the 

♦ global variable "tern" and true is returned, 

* Otherwise, false is returned, 

♦ / 

loo-term ( ) 

{ 

#lf debugif 

printf ( "Entered Log-term, 0); 

«endif 

if ( log-exp() ) 

< term = log-result; 
return(true) ; 

> 

if (token-type == id-token) 

< strcpy(symld,token) ; 
lookupO; 

term = symval; 

nextO; /♦ bypass Identifier 

term = symval; 

*if debugif 

printf ( "----Identifier value %d was found.0,term) ; 

#endif 

return(true) ; 

> 

if (token-type == Int-token) 

{ term = atol(token); 

nextO; /* bypass Integer ♦/ 

«lf debugif 

printf ( "----Integer value %d was f cund , 0 , term ) ; 

#endif 

return ( true ) ; 

> 

return(false) ; 

> /♦ end log-term */ 
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/* 

* COMPUTE performs th« operation specified in the 

* paraireter "op" and returns a value of true or false, 
*/ 



corrpute(lhs,op,rhs) 
int ihs, rhs, foe; 

{ 

#if debugif 

printf ( "Entered corrpute with %d %s 
#endif 

if ( l strciPDCop , "EO" ) ) 

< if (Ihs == rhs) 
returnCtrue) ; 
return(false) ; 

> 

if ( I stretrp (op , "LT" ) ) 

{ if (Ihs < rhs) 
return ( true) ; 
return (false) ; 

} 

if ( lstrcirp(op,"GT") ) 

{ if (Ihs > rhs) 
return ( true ) ? 
return( false) ; 

> 

if ( JStrCffP(Op,"NE") ) 

{ if (Ihs != rhs) 
return(true) ; 
return(false) ; 



} 

if ( l stremp (op , "LE" ) ) 

( if (Ihs <= rhs) 
return(true) ; 
return(false) ; 

> 

if ( lstrcrrp(op, "GE" ) ) 

< if (Ihs >s rhs) 
return(true) ; 
return(false) ; 

> 

if ( !strcrrD(op , "AND" ) ) 
{ if (Ihs f. rhs) 
return ( true ) ,* 
return( false) ; 



> 

if ( 1 strerpp (OP , "0? " ) ) 
{ if (Ihs I rhs) 
returnCtrue) ; 
returnC false) ; 

} 



if ( istrcppcop, "NCT" ) ) 
returnC llhs ); 



%d , 0 , Ihs , OP , rhs ) ; 
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If ( istrcrrpCop, "CCN") ) 

< putsCCON is not yet irnpleirentedC ) ; 
return( false) ; 

> 

> /♦ end compute */ 



& 
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/* 

* CASE. STATEMENT executes a set of statements based 

* upon the case variable, if one of the cases matches 

* the value of the case variable, that set of statements 

* is executed. If none match, the otherwise set of 

* statements Is executed, 

* 

* Functions used: lookup, next, case.num, 

* error (23/31/32/33/55) , statements 

* Globals used: token, token-type, symld, symval 

* Constants used: id. token, Int.tcken, 

* 

* Author: Dennis J, Rltaldato 

* Last update: 22 Sep 1993 
*/ 

flnclude <stdlo,h> 

^include "olobal , interp” 

Int caseval; 
case. statement () 

< 

#lf debug 

printfC’ CASE-STATEMENT entered. 0); 

*erdlf 

If (token. type == id. token) 

{ strcpy ( symld , token ) ; /» get case variable */ 

if ( I icokupO ) /* and save Its value */ 

{ error(55); /* undefined variable */ 

return ; 

} 

caseval = symval; 

} 

else If (token-type == int. token) 
caseval = atoi(token); 
else 

( error(23); /♦ not integer or valable */ 

return ; 

} 

next(); /♦ bypass case variable »/ 

if ( strcmp (token ,":" ) ) 

{ errorOl); 
return; 

> 

nextO; /* bypass : */ 

if ( I case.numo ) 

( If ( strcmp(token, "OTHERWISE") ) 

{ error(32); 
return ; 

> 

nextO; /♦ bypass OTHERWISE */ 

If ( strcmp ( token ,":" ) ) 

( error(31); 
return; 
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} 

nextn? /♦ bypass ; */ 

state PcntsC); 

> 

If ( strcinp (token , "ENDCASE" ) ) 

{ errorC33); 
return; 

> 

nextC); /♦ bypass ENDCASE ♦/ 

} /* end case. stateirent */ 
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/* 

* CASE.MIM executes a set of state trents based upon 

* the case variable. If one of the cases matches 

* the value of the case variable, that set of statements 

* Is executed and true is returned. 

* Otherwise, false Is returned. 

* 

* Functions used: lookup, next, case»nu(n, error(55), statements 

* Globals used; token, token. type, svrrid, symval 

* Constants used; id. token, Int. token, 

* 

* Author: Dennis J, Rltaldato 

* Last update; 22 Sep 1983 

*/ 

flnclude <stdlo.h> 
case.num ( ) 

( 

int found; 

Int saveval; 

for (found=false; ( strcmp ( token , "CTHERW ISE" ) 1 =0 ) & (! found); ) 
#lf debugcase 

printf ( "--Inside for loop.O); 

#endlf 



If (token. type == id. token) 
{ strcpyCsymid , token) ; 






maybe an identifier 


♦ / 


#if debugcase 






' 




printf("An identifier token, %s. 


was found 


, 0 , token ) ; 




#endif 










next C ) ; 

if ( i strcmp ( token ,";" ) ) 




/♦ 


bypass identifier 


♦ / 


{ nextO; 

if C i lookupO ) 

{ e r r 0 r ( 5 5 ) ; 
returnCfalse) ; 

> 

if (caseval s= sytttval) 




/♦ 


bypass ; 


*/ 




/* 


check this case Item 




found = true; 

> 




/* 


against the case value 


*/ 


> 

else if (token. type == int. token) 


/♦ 


maybe an Integer 


♦ / 


{ saveval = atoi(token); 










#if debugcase 

printf("--An integer case option 
♦endif 


O 

a 


was 


found . 0 , saveva 1 ) ; 




next ( ) ; 




/* 


bypass Integer 


*/ 


if ( l strcmp ( token ,":" ) ) 
{ nextO; 




/♦ 


bypass : 




If (caseval saveval) 




/< 


check this case item 


*/ 


found s true; 




/* 


against the case value 


*/ 



} 
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} 

else /♦ must not be the proper ♦/ 

{ while (strcmp(token , " ; " ) ) /♦ case so s'<lp rest of line*/ 

next ( ) ; 

#if debugcase 

or Intt C "--No valid case num was found, 0); 

#endif 

nextO; /» bypass ; ♦/ 

> 

} /♦ end-for 

#if debugcase 

pr intf ( "--End of for loco.O); 

#endif 

if ( J found ) 
return Cfalse) ; 
statements ( ) ; 



while ( strcmpctoken, "ENDCASE" ) ) 


/♦ 


skip remaining 


statement*/ 


next ( ) ; 


/♦ 


in the case 


*/ 


return(true) ; 








> 


/* 


end-case_num 


*/ 
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/♦ Lcop repeats a set of staterrents a specified nuffber 

♦ of titres. Any number of repetitions may be specified 

♦ via either a number constant or variable entry. 

♦ Only one level of looplro is implemented in this 

♦ version. To Implement multiple levels, chanqe the 

♦ loop. file variable name to an array. Then step 

♦ through that array. 

♦ Functions used: next, error (23/55 ) , lookup 

♦ Globals used: looc.cnt, symld, symval, loop-file 

♦ token, token-type, string, sotr 

♦ Constants used: int-token, id-token, ilnesiz, NULL, 

♦ LOCF-FILE 

» 

♦ Author; Dennis J. Rltaldato 

♦ Last update; 22 Sep 1993 
*/ 

♦include <stdlo.h> 

♦include "global . interp” 
looo-statement () 

( 

Int save-cnt = 0: 

♦if debug 

printf ("LOOP-STATEMENT enter ed. 0) ; 

♦endlf 

if (token-type == id-token) 

{ strcpy ( symid , token); 
if ( lookupO ) 

save-cnt s symval; 
else 

error (55) ; 

> 

else if ( token-type == int-token) 
save-cnt = atol(token); 
else 

( error(23); 
return; 

> 

nextO; /* bypass loop count variable */ 

n NOTE: ♦/ 

/♦ Each line must terminate with a newline character. */ 

/* Lin-len should always point to this nEwLIne character. */ 

/♦ Except, when adding a string, the NEwLINE is added at the*/ 

/* end of each line and at the end of the complete string. ♦/ 

looo-flle s f open (LOOP-FILE , "w" ) ; 
while C strcmp(token,"ENDLCCP") ) 

( if ( token-type 1= str-tcken ) 

( fputs (token , looo-f lie) ; /* add identifier/number to file*/ 
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£puts("0, loop-file) 



> 

else 

{ fDUtSC" 

fputs(strlng, loop- file); 
foots ( ” 

> 



n e X t ( ) ; 

> 

loop-cnt = save-cnt; 
fclose(loop-flle); 


/* 


bypass 


current 


token 


»/ 


/* 


close 


as write 


file 


♦ / 


loop-file = £oper(LCCP-FILE, 


/* 

" r " ) ; 


reopen 


for input 


»/ 



#if debuQloop 

prlntf C ”--111 loop, bypassing token %s0, token); 

#endi£ 

nextO; /♦ bypass the word "ENDLCOP" */ 

#lf debugloop 

printf ( "--Leaving loop with token %s0, token); 

•endlf 
return ; 

> /♦ end loop-statement »/ 
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^include <stdlo,h> 

#irclude "global . Interp " 
create () 

printfC* create entered,©); 
while Ctoi^enCO] 1= 
next ( ) ; 



) 



/* end create 



♦ / 



^Include <stdio,h> 

• Include "global . Inter? ** 
dlsolay () 

< 

crlntfC" DISPLAY entered,©); 
while (toXenCO] 1= ';') 
next ( ) ; 



> 



/* end dislpay 



♦ / 
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/♦ 

♦ Error perforfps error processlnq. Deoendlnq on the input 

♦ parameter "type" a message Is printed at the user's console 
» and the function either returns or terminates the nrograrp. 

♦ 

* Author; Dennis J, Rltaldato & David J, Smanla 

♦ Last update: 22 Sep 1983 

*/ 

# include <stdlo,h> 

#lnclude “global , interp” 
error (type) 



Int 


type; 


/» 


ERROR 


TYPES ARE: 


♦ / 


if 


(type <= 10) 


/* 


1-10 


System errors 


*/ 



< printf SYSTEM ERROR **** 0); 



switch ( type ) 

< case 1 : 
exltC ) ; 
case 2: 

printf (''Symbol table exceeded, 0); 
exltC ) ; 
case 3: 

printf ( "Prernature end of input encountered , 0 ) ; 
exltC); 
case 4: 

printf (“Unrecognized character, %c, In llne:0,*iptr) ; 
printf (”%sO,llne ); 
return; 
case 5: 

printf ("String length exceeds %d in line:0,strlngslz) ; 
printf C"%sO,llne); 
exitO ; 
case 6: 

printf ( "Unable to open file - checK <FN> Is capltallzedO) ; 

exit ( ) ; 

return; 



> 


/* 


endcase 




*/ 


> 


/» 


endlf 1-10 




*/ 


else if (type <= 50) 


/* 


if 11-50 Reserved 


word 


*/ 


< printf ("♦♦»♦ SYNTAX ERROR 


**** 0); 


/* syntax errors 


♦ / 





switch ( type ) 

( case 11: 

printf ("PROGRAM"); 
break ; 
case 12; 

prlntf("AN IDENTIFIER"); 
break ; 
case 14: 

printf ("END. ") ; 
break; 
case 16: 

printf ("THEN"); 
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break ; 
case 17: 

printf C'’ENCIF") ; 
break ; 
case I?: 

orintf C"=" ) ; 
break ; 
case 20: 



Printf ( "Device 'CRT' or a filename"); 
break; 
case 21: 

printf("^N ARITHMATIC CPERATCR"); 
break; 
case 22: 

PrintfC"AN ARITHMETIC EXPRESSION"); 
break ; 
case 23: 

printfC"An integer or variable loop count"); 
break; 
case 24: 

printfC"An integer, identifier, string or expression") 



break ; 
case 25: 

crintf ( "Device 'CRT' or 'LST' or a filename"); 
break; 
case 26 : 

crintf ("Filename -- (<FN> I.<FT>)) -- "); 
break; 
case 2.7: 

prlntfC"— ) --"); 
break ; 
case 30: 

orintf ("Filetype — (<FN> [,<FT>]) --"); 
break ; 
case 31: 

prlntfC"-- : — "); 
break ; 
case 32: 

printf ("CTHERKISE") ; 






break ; 
case 33: 

printf ("ENDCASE") ; 
break; 
default; 

crintf (" $SSS$ SYSTEM ERROR « 1 - %d sssss ",type); 

printf (" PLEASE NOTIFY EITHER DENNIS J. RITALDATO (215) "); 
crintf ("441-2107 CR DAVID J. SMANIA (408) 646-8182, 0); 
return; 

} /* endcase */ 

crintf (" was expected, but %s was found at %s , 0 , token , Ictr ) ; 
while (tokentO) != ';') skip remainder of line */ 

next( ) ; 
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return; 



erdlf 11-30 



("No legal 



> 

else if (type <= 70) 

( sv'itch(type) 

{ case 51: 
prlntf 
break; 
case 53: 
prlntf 
break; 
case 54: 
prlntf ("An 
break ; 
case 55: 

prlntf ( "Undefined 
break; 
case 56: 

crlntf ( "Cannot 
break; 
case 57: 

crlntf ("Data 
break; 
case 58: 
return; 
case 59: 
return; 
case 60: 
return; 
default : 
prlntf 
prlntf 
prlntf 
return; 



/♦ erdlf 11-30 */ 

/♦ if 51-70 General syntax */ 

/* errors */ 

CoiPirand Language statement was found"); 



("; expected") 



IF statement trust have a logical expresslcn") 



identifier, %s 



token ) 



read from tbe list device") 



type tjiisiratch. A string type was excected") 



("$ssss SYSTEM ERROR # 1 - %d $SSSS ",type); 

(" PLEASE NOTIFY EITHER DENNIS J, RITALDATO (215) "); 
(" 441-2107 OR DAVID J. SMANIA. 0); 



> 

prlntf 

while 



( 



/* endcase 

(" at %s in llne:112s0,lctr,line); 
s trcmp ( token ,";" ) ) nextO;/* skip 
/* endlf 51-70 
/» end error 



rest 

*/ 



*/ 



of line */ 



*/ 
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